Web2 supply-chain flaw with Web3 consequences: the Trust Wallet Chrome extension incident

Summary

A malicious update of the Trust Wallet Chrome extension was published via the Chrome Web Store, and the injected code was designed to exfiltrate users’ seed phrases (mnemonics). Once an attacker had the seed phrase, they didn’t need approvals, phishing signatures, or UI tricks. They restored the wallet elsewhere and drained funds directly. Trust Wallet later urged users to update to v2.69 and stated they would refund impacted users after confirming ~$7M in losses.

This incident wasn’t a smart-contract exploit or a chain-level break. It was a Web2 software supply-chain compromise that hit Web3 where it hurts most: private keys.

What makes this case especially instructive is where the failure happened: release infrastructure, browser extension distribution, and analytics plumbing. Pure Web2 components that became a direct pipeline into Web3 assets.

Event Flow

1. Attacker prepared the infrastructure

The attacker registered the look-alike domain metrics-trustwallet.com, with the goal of clearly aiming to blend exfiltration traffic into something that appears like ordinary analytics/telemetry.

Request activity tied to api.metrics-trustwallet.com begun appearing before the attack, suggesting the collection endpoint was live and tested before the public incident window.

2. Malicious code pushed to Chrome Web Store

The compromised release is identified as Trust Wallet Chrome extension v2.68. Trust Wallet leadership stated the malicious build appears to have been published using a leaked Chrome Web Store API key, bypassing their standard manual release process.

The attackers leveraged PostHog, a legitimate analytics library, as the harvesting/exfiltration mechanism.

3. Users started reporting wallet drains

On-chain investigator ZachXBT publicly flagged the pattern of drains, and researcher Akinator tied the activity to the v2.68 extension update.

4. Trust Wallet confirmed the breach

Trust Wallet confirmed that the incident impacted Chrome extension v2.68 and instructed users to upgrade to v2.69, with public communications indicating refunds for affected users. Reporting emphasizes that this was a compromised browser extension, not a chain-level exploit.

Funds extraction flow

Trigger on unlock: Analysis indicates the logic was executed on wallet unlock, not only on “import seed,” meaning routine usage could trigger theft.

Enumerate wallets: The code iterates across stored wallets, not just the currently selected one.

Request mnemonic: For each wallet it triggers a “get mnemonic phrase” request, retrieving the seed in encrypted form.

Decrypt using unlock secret: It uses the user’s unlock-time password or passkeyPassword to decrypt the mnemonic.

Hide in telemetry payload: The mnemonic is embedded into a field such as errorMessage, making it look like normal “unlock telemetry” rather than an obvious secret dump.

Exfiltrate via analytics channel: The data is sent to attacker infrastructure api.metrics-trustwallet.com, leveraging a hijacked PostHog analytics flow to blend with expected outbound requests.

Mitigation techniques

Controls that would have stopped the attack / reduced the impact:

Release hardening: lock down Chrome Web Store publishing (strong MFA, scoped keys, hardware-backed auth, approval workflows).

Build integrity: implement automated diffing of bundles.

Network controls: watch for new analytics hosts; allowlist expected telemetry domains; alert on lookalike domains.