Skip to main content
CybersecurityPrivacy & Surveillance

Crypto Wallets Expose Users to Cross-Site Tracking Risks

Person sitting at desk with laptop and crypto wallet interface surrounded by multiple monitors in a university setting.

“The wallets themselves leak enough to link and track the people using them,” researchers at KU Leuven wrote after testing 85 browser-extension crypto wallets.

Who ran the study and what they tested

The DistriNet security group at KU Leuven ran real wallets against real Web3 sites, testing 85 of the most popular crypto-wallet browser extensions. Together those extensions account for about 35 million installs listed on the Chrome Web Store, the researchers say. The paper was posted on arXiv on July 7 and is scheduled for presentation at the PETS 2026 privacy conference in Calgary, July 20–25.

Problem 1: separate addresses get linked

Many users hold multiple addresses to keep activities separate. The study found that wallets regularly make requests to outside servers that include addresses in the clear, and those requests can link a person’s different addresses.

Seventeen wallets exposed connections between a user's separate addresses. Thirteen did so by bundling two addresses into one request; four revealed links by firing separate requests within milliseconds of each other. The wallets that behave this way cover roughly 23 million of the installs the team studied. Any server that receives those requests — or anyone who later obtains that server’s logs — can stitch addresses into a single profile.

Problem 2: logging out often does not revoke access

The researchers identified a second cluster of issues rooted in how wallets announce themselves and manage permissions. Thirty-six of the 85 wallets explicitly announce their presence to pages, creating a persistent fingerprint of which wallets a browser has installed; those 36 account for about 82% of the installs examined.

When a user clicks Disconnect or Logout, they typically expect the site to lose access. The study tested 30 popular Web3 apps and found only 11 actually sent a revoke command. The remaining apps merely cleared their own screens. Even when a revoke command was sent, many wallets ignored it: in 22 of the 36 wallets the site could still read the user’s address after the app asked the wallet to revoke access. That access survived clearing cookies and restarting the browser because the stale permission remained inside the extension until a user removed the site by hand from the wallet’s “Connected Sites” list. The researchers warn that an address is a globally unique tracking tag that does not vanish with ordinary cookie-clearing.

Problem 3: addresses handed out from inside embedded frames

Of those same 36 announcing wallets, 23 will hand an address to a page loaded inside an embedded frame. On its own that behavior is inert; the study documents how it becomes an unmasking vector if the same tracking script runs on both a connected crypto app and an ordinary website.

In that scenario a tracker on an ordinary site quietly loads the previously authorized crypto app inside an invisible frame. Because the app’s page was already authorized by the wallet and the wallet answers from inside the frame, the wallet can hand the address back to the script without a user click — provided the app allows being embedded. If the ordinary site already holds a name or email, the linkage converts a pseudonymous wallet address into a named, browsable profile. The researchers demonstrated this path is real and usable; they explicitly did not claim trackers are already executing it at scale.

Vendor responses, retests, and fixes

The KU Leuven team focused disclosure on the cross-site frame problem and told affected wallet makers before publishing. By a February 2026 retest, Coinbase Wallet and Coin98 had fixed the issue; Hana Wallet fixed it later. The paper notes eight vendors replied via their bug-bounty channels, but "most declined to treat it as a bug."

  • MetaMask called it "a known issue," closed the report as a duplicate, and said it had "no immediate plans to stop injecting its provider because that would break too many apps."
  • Rabby judged the attack impractical, calling it "virtually impossible," and concluded that "the vulnerability does not exist."
  • OKX agreed the finding was technically correct but closed it as informational because it "exposes data without stealing money."
  • Bybit, Backpack, and Core described the issue as low-risk or out of scope. The researchers published the full replies in their repository.

What this means for end users and technologists

For users, the immediate steps are partial. The researchers recommend opening your wallet and clearing old site permissions — which removes stale permissions and stops the logout-tracking described in Problem 2 — and using throwaway wallets for risky activities. Their demo runs in the browser and, they say, stores nothing. Keeping distinct wallets or separate browser profiles for different activities reduces linkage risk but does nothing about addresses sent in the clear to external servers or the installed-wallet fingerprint.

For wallet developers and Web3 app builders, the paper points to two concrete design changes: stop exposing wallets inside embedded frames and adopt an ecosystem standard that defines what a real logout/revoke must do. Those are the fixes the researchers single out as beyond the reach of individual users.

The study builds on 2023 work by Christof Ferreira Torres and colleagues, extending prior findings about address leaks to map cross-site tracking paths and the specific ways a pseudonymous address can be tied to a real identity. Unlike malicious extensions that steal keys, the researchers emphasize this is not a hack: the extensions behave as designed, and many vendors have said, in effect, that the design is acceptable. The researchers conclude the real fix will require wallets to stop answering from embedded frames and an agreed standard for what logging out actually means.

https://thehackernews.com/2026/07/study-of-85-crypto-wallet-extensions.html