How browser extensions expose crypto to a fatal design flaw the industry ignored, bleeding $713M in 2025

Trust Wallet’s Chrome extension shipped a malicious update in December, exfiltrating wallet data and draining roughly $7 million from hundreds of accounts before the company pushed a fix.

The compromised version 2.68 was live for days, auto-updating in the background, the way browser extensions are designed to. Users who followed every standard self-custody rule, such as never sharing their seed phrase, checking URLs, and using reputable wallets, still lost funds.

The attack targeted the browser layer, not the blockchain, and it exposed a persistent trade-off that the industry has spent years trying to ignore: browser-extension wallets are always-on hot wallets sitting in one of the most hostile environments in computing.

This wasn’t an isolated case. MetaMask’s security team documented a fake Google Chrome extension called “Safery: Ethereum Wallet” that lived in the official Chrome Web Store from late September until mid-November, stealing seed phrases.

Chainalysis estimates that crypto theft reached $3.4 billion in 2025, with personal wallet compromises accounting for 20% of that total, or $713 million. However, that would have been 37% without the Bybit exchange hack.

For perspective, personal wallet compromises accounted for just 7.3% of the stolen value in 2022 and 44% in 2024, indicating that attackers are following the value to wherever user keys live.

The UX/security trade-off that won’t go away

Browser extensions sit in the same environment as adware and random plugins. Campaigns like “ShadyPanda” and “GhostPoster” show how benign extensions can be updated years later with code that steals cookies or executes remote commands, via legitimate update channels.

The Trust Wallet case proves even reputable wallets can briefly ship compromised updates, and users accept them because extensions auto-update in the background. That’s the trade-off: auto-updates patch vulnerabilities quickly but also deliver bad code at scale.

Usability pushes users toward blind signing because ETH and EVM transactions are notoriously hard for regular users to read.

When approving swaps via a browser extension, most users tap “Confirm” on opaque hex blobs rather than human-readable semantics.

As a result, drainer kits exploit this by presenting transactions that appear to be routine approvals but grant full token-spending rights to attacker contracts.

The user technically approves every step, yet has no idea what is being signed. That’s not a bug in user behavior, but rather a feature of how browser wallets minimize friction.

“Best practices” still assume users can reliably verify context. For years, self-custody hygiene has meant: never share the seed, check URLs, use hardware wallets.

Those remain necessary but insufficient.

Fake extensions never directly ask for the seed phrase until the user “imports” a wallet. Conversely, they present familiar UX, leaving users to distinguish clones from the real thing.

The Chrome Web Store vetting process is supposed to catch these, but it doesn’t catch consistently.

For hardware wallet users, the Ledger Connect Kit exploit from late 2023 illustrates the same fault line. A former employee’s NPM account was phished, and attackers pushed a malicious package that injected draining code into any dApp using the kit.

Users with Ledger hardware devices still lost funds because the browser-side integration was compromised. Even with the keys still on the device, users signed draining transactions because the browser’s logic had been tampered with.

Empirical data shows that models combining hardware key storage and air-gapped signing have incident rates below 5%, compared with over 15% for software-only wallets. Wallets with phishing detection and transaction alerts reduce user-reported losses by nearly 60%.

However, adoption is the catch: day-to-day DeFi activity runs through browser extensions because they’re the only setup most users find usable. The safest configurations are too cumbersome, and the usable configurations are too exposed.

Where the attacks actually happen

The weak links in 2025 are almost all “above” the chain, such as browser, extensions, and supply chain, while most user education still focuses on what happens below, at the private key and seed storage level.

The attack paths break down into four layers.

The browser and OS layer is where info-stealer malware operates. Families like ModStealer, AmosStealer, and SantaStealer infect the machine, read extension storage, intercept keystrokes, or hook browser APIs to capture seeds and private keys at rest.

As TechRadar reported, these tools are now marketed on underground forums and Telegram as “stealer-as-a-service,” with modules dedicated to grabbing browser credentials, cookies, and wallet data, then exfiltrating them in compressed chunks.

The browser is the entry point, and extensions are the payload.

The wallet extension layer is where compromised or malicious updates operate. Trust Wallet’s version 2.68, the fake “Safery” wallet, and the malicious wallets on Chrome all added code that exfiltrated secrets or tampered with transaction requests before users saw them.

This is the UX and supply-chain trade-off in action: auto-updates are critical for patching vulnerabilities, but they also deliver bad code at scale when the update mechanism itself is compromised.

The dApp and connector layer is where libraries like Ledger Connect Kit get hijacked. When these are compromised upstream, legitimate dApps start presenting malicious transactions.

The user connects their real wallet or hardware device, sees a normal-looking prompt, and signs a drainer transaction. This layer is invisible to most users, as they don’t know which JavaScript libraries power the dapps they use, and they have no way to verify that those libraries haven’t been tampered with.

The RPC and blockchain layer is where the attack completes. Once a malicious transaction is signed and broadcast, the rest of the stack works as designed.

Funds move, and the only remaining defenses are monitoring, rapid incident response, and any off-chain recovery measures the ecosystem might have. By this point, the damage is done. The blockchain didn’t fail, but the layers above it did.

What BTC and ETH holders should actually do

The checklist for using browser wallets hasn’t changed much in principle, but the emphasis needs to shift toward isolating the browser layer from the assets that matter.

The table below breaks down the key areas where users can reduce exposure without abandoning browser wallets entirely.

The industry knows the problem and hasn’t fixed it

The Trust Wallet incident, the fake Chrome extensions, the Ledger Connect Kit exploit, and the rising share of personal wallet compromises all point to the same conclusion: the browser is a hostile environment, and “self-custody best practices” around seed phrases and hardware still don’t fully address that.

The failure mode has shifted from users mishandling keys to attackers compromising the UX layer, and the industry has known this for years.

The architecture hasn’t changed because the alternatives are either too cumbersome for mass adoption or too centralized to fit the ethos.

Until browser wallets can be isolated from the broader browser environment, or until transaction signing happens in a truly air-gapped flow that doesn’t rely on JavaScript libraries and auto-updating extensions, the trade-off will persist.

Users can follow every rule, use hardware wallets, never share their seeds, and still lose funds because the code they’re interacting with, and which they have no practical way to audit, has been silently compromised.

That’s not a user-education problem. It’s an architecture problem, and no amount of “best practices” will fix it.