KU Leuven: 85 wallet extensions leak addresses cross-site

The way a browser-extension wallet talks to the page it’s sitting on hasn’t changed much in years. It injects a global object, listens for postMessage traffic, and answers whatever the page asks. On paper the wallet decides when to respond. In practice, a study out of KU Leuven’s DistriNet group finds it responds to more people than the user thinks — including invisible embedded frames and third-party trackers riding shotgun on the same page load.

The paper tests 85 Chrome Web Store wallets with a combined ~35 million installs and lands at PETS 2026 in Calgary next week; an arXiv preprint went up on July 7. It reads less like a bug report on any one wallet and more like a survey of what the browser-to-wallet wire actually looks like in the wild in 2026 — and the answer is legacy plumbing that nobody has cleaned up because it still works well enough to move money.

Four categories of leak, all counted

The findings, per DistriNet as reported by The Hacker News:

• Address linking — 17 wallets, ~23M installs. Separate cryptocurrency addresses either bundled into a single request or fired milliseconds apart, close enough that any listening server can attribute both to one person. Once linked, they don’t unlink.
• Cross-site tracking via embedded frames — 23 of 36 wallets tested for it. Addresses handed back to invisible embedded frames on the page. If the framing site already has a name or an email tied to the visitor, the crypto identity is now on that record too.
• Wallet-detection fingerprinting — 36 of 85. Each wallet announces itself to any page it loads. No connection needed. The set of wallets a browser has installed becomes a fingerprint on its own, even before the user clicks anything.
• Broken logout — 36 of 85, roughly 82% of installs studied. Sites often don’t send a revocation command when the user “disconnects.” Even when they do, 22 of the 36 wallets ignore it — the session survives a browser restart. Manually clearing “connected sites” from the wallet UI does not always get the state that the extension has retained in memory or in storage.

The framing here matters. A crypto address is supposed to be a pseudonym. Address linking plus a cross-site fingerprint plus a session that outlives an explicit disconnect is deanonymization by construction — not by exploitation of any single bug, but by the accumulated behavior of the wire between the extension and the page.

Vendor response, mixed as usual

Per DistriNet’s coordinated disclosure:

• Fixed — Coinbase Wallet, Coin98, Hana Wallet.
• Rejected or downgraded — MetaMask called it a “known issue.” Rabby said the described tracking was “virtually impossible.” OKX marked it informational only. Bybit, Backpack, and Core categorized the findings as low-risk or out-of-scope.

The rejections are consistent with each other: the wallets in that group don’t dispute the mechanism, they dispute that the mechanism is a vulnerability in the wallet’s threat model. That’s a defensible position for a wallet whose threat model is “attacker steals the key.” It is not a defensible position for a wallet whose users assume separate addresses stay separate.

Related coverage

• Coinspect’s Ill Bloom disclosure: weak PRNG drained $5.1M from crypto wallets — a different failure mode in the same category of software, same weekend.
• ModHeader carried a dormant collector to 1.6M installs — a reminder that “store-signed” is not “safe” for browser extensions.
• InjectiveLabs SDK-TS npm 1.20.21 shipped a wallet stealer — the supply-chain side of the wallet-extension surface.

What to actually do

The single most specific defensive detail in the paper is the one that isn’t a user setting: 22 of 36 wallets do not honor a site’s disconnect request, so revoking permissions from within the wallet UI does not necessarily revoke the session the extension has been keeping alive. That has to be a wallet-side fix — installing a newer build once the vendor ships one, or replacing the wallet with one of the three that already fixed. Until then, DistriNet’s own recommendation is the pragmatic one: keep separate wallets for separate activities, and don’t assume the “connected sites” list in the wallet UI reflects the extension’s real state.