Trust Wallet Chrome Extension Hack Drains $8.5 Million

On December 24, 2025, a malicious version of the Trust Wallet Browser Extension — version 2.68 — was silently published to the Chrome Web Store without passing through the company's internal review process. Over the next two days, the attacker drained approximately $8.5 million from 2,520 wallet addresses. The root cause was not a flaw in the extension's code. It was a supply chain compromise that had begun a month earlier, and that no one had yet connected to Trust Wallet.

How the Attack Was Set Up

In November 2025, an industry-wide supply chain attack known as Sha1-Hulud swept through the software development ecosystem, targeting commonly-used npm packages. The attack affected companies across multiple sectors. Among the casualties was Trust Wallet — though the consequences wouldn't become visible for another month. Through the compromised packages, the attacker gained access to Trust Wallet developer secrets stored on GitHub, including the browser extension's source code and, critically, the API key used to publish builds directly to the Chrome Web Store.

With that key in hand, the attacker had everything they needed to push a new version of the extension without going through Trust Wallet's internal approval pipeline. They registered a lookalike domain — metrics-trustwallet.com — to host the malicious payload, and embedded a reference to it inside a tampered version of the extension built from the stolen source code. There was no traditional code injection. The attacker simply modified a version they already had full access to.

The malicious build was submitted to the Chrome Web Store for review. Once it passed Google's automated checks, it was released automatically — bypassing Trust Wallet's internal controls entirely.

The Drain

Users who opened the extension and logged in between December 24 and December 26 had their sensitive wallet data silently collected and forwarded to the attacker's server. From there, the attacker executed unauthorized transactions, draining wallets across 17 controlled addresses. The attack window was narrow but precise. Users who logged in after December 26 at 11:00 UTC were not affected. Mobile app users were never at risk.

The first public reports of suspicious wallet-draining activity emerged on December 25. On-chain researchers 0xAkinator and ZachXBT identified and began tracking the attacker's addresses. Security firm Hashdit and Trust Wallet's internal monitoring flagged anomalies simultaneously. White-hat researchers launched a DDoS attack against the attacker's malicious domain in an attempt to disrupt data exfiltration and limit further losses.

Trust Wallet moved quickly to roll back the extension to the last verified clean version — 2.67 — reissued as 2.69 — and published urgent instructions for users to update.

The Response and Reimbursement

Trust Wallet confirmed the incident and announced it would voluntarily reimburse affected users. The verification process proved complex. Of the more than 5,000 reimbursement claims submitted, only 2,520 wallet addresses were verifiably connected to the incident — suggesting a significant volume of fraudulent claims attempting to siphon funds meant for actual victims. The team implemented a multi-point verification process to distinguish legitimate victims from bad actors, working through cases individually.

A browser extension verification tool was also developed and released in version 2.70, giving affected users an additional way to authenticate their claims.

What This Tells Us

The Trust Wallet incident is not primarily a story about a compromised extension. It is a story about what happens when developer infrastructure — GitHub secrets, CI pipelines, publishing credentials — becomes the attack surface. The extension itself was never directly breached. The attacker obtained the source code and publishing key through a third-party dependency that had nothing to do with Trust Wallet's own codebase.

This is the defining feature of supply chain attacks: the target is not the product, but the tools and credentials used to build and ship it. Once an attacker has a valid publishing key and the source code, they can produce a version of your software that looks entirely legitimate — because it is built from your own code and signed with your own credentials. Standard code audits and internal review processes are bypassed entirely.

For the broader industry, the lesson is about the blast radius of developer tooling compromises. API keys that grant direct access to software distribution channels represent a category of credential that deserves the same protection as private keys to protocol admin functions — because in practice, they are just as powerful.