We manage your security to weather the AI storm →

← Resource Hub

The Trust Wallet Extension Hack Explained

By Owen Thurm Published 5 min read

The Trust Wallet Extension Hack Explained

Quick answer. In December 2025, Trust Wallet's Chrome Web Store API key, leaked in an attack it links to Sha1-Hulud, let an attacker ship a backdoored extension. Trust Wallet counts 2,520 drained addresses, about $8.5M. Signed uploads target that path.

Watch: The Trust Wallet Extension Hack Explained 1:39
Video transcript

The attacker held the publishing key. In December 2025, a Trust Wallet extension version its team never approved went live, and no code flaw was needed.

Trust Wallet says the Sha1-Hulud npm attack likely exposed developer GitHub secrets, including its Chrome Web Store API key. A tampered version 2.68 skipped internal approval and went live December 24.

Koi Security found the code sent seed phrases to the attacker on every unlock, by password or biometrics, for every wallet in the account. The seeds were hidden in what looked like telemetry.

Trust Wallet counts 2,520 wallet addresses drained, with about 8.5 million dollars linked to attacker addresses. It is voluntarily reimbursing affected users, case by case.

The leaked key went straight around Trust Wallet's internal approval. A release control only counts if the store enforces it.

Opt in to verified CRX uploads and keep that signing key apart from GitHub and CI secrets. Rotate store credentials after supply chain incidents, alert on unknown store versions, and review every network call at unlock.

Two areas of Guardian's Browser Extension Pentest map to this incident: key and session storage, and supply chain, including who can publish updates. Source code is effectively required, since a store download cannot confirm every path was reviewed.

Read the full breakdown below, or talk to Guardian about testing your wallet extension's release path.

On December 24, 2025, a Trust Wallet extension version its team never approved went live on the Chrome Web Store.

Koi Security found it sent seed phrases to the attacker whenever a user unlocked the wallet, The Hacker News reported. Trust Wallet urged about one million extension users to update.

No flaw in the wallet's code was needed. The attacker held the key that publishes it.

What Happened

Trust Wallet's incident update, first published December 30, 2025, sets out the sequence:

  • November 2025: the Sha1-Hulud npm attack exposed Trust Wallet's developer GitHub secrets.
  • Those secrets gave the attacker the extension's source code and Chrome Web Store API key.
  • December 2025: the attacker registered metrics-trustwallet.com to host malicious code.
  • December 24: a tampered version 2.68 went live, outside Trust Wallet's standard release process.
  • December 25: the first wallet draining was publicly reported.
  • Trust Wallet rolled back to clean version 2.67 and released it as 2.69.

Trust Wallet says it has "high confidence" the incident is likely related to Sha1-Hulud. Its investigation of the exact attack vector is ongoing.

Affected users opened version 2.68 and logged in between December 24 and 26. Trust Wallet says mobile app users, other versions and logins after 11:00 UTC on December 26 were not affected.

The Hacker News describes Sha1-Hulud as the second wave of the Shai-Hulud npm supply chain attack. Wiz reported that it pushed stolen developer and CI/CD secrets into GitHub repositories.

For how Shai-Hulud spread through npm, see dApp frontend supply chain security.

How the Attack Worked

A key that skips approval

Trust Wallet's releases normally require "internal approval/manual review." The leaked key gave "full CWS API access," so builds could be uploaded without it.

The attacker built the tampered version from an earlier codebase, taken through the same leak. It "was released automatically upon passing Chrome Web Store review approval," Trust Wallet says.

A backdoor on unlock

Koi Security analyzed the malicious code, The Hacker News reported. Its findings:

  • The code harvested wallet mnemonic phrases and sent them to api.metrics-trustwallet[.]com.
  • It ran on every unlock, not only when a seed phrase was imported.
  • It ran whether the user unlocked with a password or biometrics.
  • It looped through every wallet in the account, not just the active one.
  • Seed phrases were hidden in an "errorMessage" field inside what looked like unlock telemetry.

Koi found the attacker's infrastructure was staged by December 8, more than two weeks before the release. "This wasn't opportunistic. It was planned," Koi wrote.

Timeline and Loss

DateEventSource
Nov 2025Sha1-Hulud exposes developer GitHub secretsTrust Wallet
By Dec 8Attacker infrastructure stagedKoi, via The Hacker News
Dec 24Malicious version 2.68 publishedTrust Wallet
Dec 25First wallet draining publicly reportedTrust Wallet
Dec 25Trust Wallet tells 2.68 users to upgrade to 2.69BleepingComputer
Dec 26, 11:00 UTC2.68 logins after this point not affectedTrust Wallet
Dec 30Incident update publishedTrust Wallet

Early figures were lower. Binance founder Changpeng Zhao posted on X that "$7m" was affected and that Trust Wallet would cover it, BleepingComputer reported.

Trust Wallet's own figures:

  • 2,520 wallet addresses were affected and drained.
  • About $8.5 million in assets is linked to 17 attacker-controlled addresses.
  • Over 5,000 reimbursement claims arrived, many duplicate or false.

Trust Wallet says the same attacker addresses also drained wallets not tied to this incident. Its figures may change as it tracks more addresses.

It decided to voluntarily reimburse affected users, reviewing claims case by case. Its update gives no reimbursed amounts.

As of its July 17, 2026 revision, the update says the investigation and reimbursement workflow are still ongoing.

Scammers followed. A fake fix-trustwallet[.]com site asked visitors for their seed phrase, BleepingComputer reported.

What It Shows for Wallet Extensions

This is the publishing path that hit Cyberhaven a year earlier, with a wallet's keys on the other side. See the Cyberhaven extension attack explained.

One leak led to the next

An npm attack exposed GitHub secrets. Those held a store key. The store key could update every install.

Any secret in a developer's environment is only as safe as every package that runs there.

The store API key is a release key

Trust Wallet's internal approval existed. The key went around it, and Chrome's review passed the build.

A release control only counts if the store enforces it.

Unlock is the moment that matters

A wallet decrypts its seeds at unlock. A malicious build that runs there defeats strong vault encryption.

Telemetry makes a good hiding place, as the errorMessage field showed.

Controls that target this path

  • Opt in to verified CRX uploads, so every update must be signed with your key.
  • Keep that signing key apart from GitHub and CI secrets.
  • Rotate store API credentials after any supply chain incident that touches your developers.
  • Alert on any store version missing from your release log, and diff it against source.
  • Review every network call in the unlock path, including analytics and error reporting.

Chrome says verified uploads "can prevent malicious updates if your developer account is compromised." That holds only if the signing key does not leak too.

Our browser extension pentest guide covers the full pipeline. For an older flaw that could expose extension seed phrases, see the MetaMask Demonic vulnerability.

How Guardian Tests This Surface

Guardian's Browser Extension Pentest tests what a hostile site can extract and what a bad update could do.

Two of its six areas map to this incident:

  • Key and session storage: where keys, seeds and tokens live, how they are encrypted, and what is readable while unlocked.
  • Supply chain: bundled dependencies, build integrity, and who can publish a store update.

The others are permissions and manifest, content scripts, internal messaging and signing flows. Source code is effectively required: a store download cannot confirm every path was reviewed.

For the secrets and pipelines behind a store key, Guardian's infrastructure pentest covers IAM, secrets and CI/CD.

Frequently Asked Questions

How was the Trust Wallet extension hacked?

Trust Wallet says developer GitHub secrets, exposed in an attack it links to Sha1-Hulud, gave an attacker its Chrome Web Store API key. The attacker uploaded a backdoored version 2.68 that skipped internal approval and went live after Chrome's review.

How much was stolen in the Trust Wallet extension hack?

Trust Wallet says 2,520 wallet addresses were drained, with about $8.5 million in assets linked to 17 attacker-controlled addresses. It says the figures may change as more addresses are tracked.

Who was affected by the Trust Wallet extension hack?

Users of extension version 2.68 who opened it and logged in between December 24 and 26, 2025. Trust Wallet says mobile app users, other extension versions and logins after 11:00 UTC on December 26 were not affected.

Is Trust Wallet reimbursing victims?

Yes. Trust Wallet decided to voluntarily reimburse affected users and reviews claims case by case. It received over 5,000 claims, many duplicate or false, and says it will never ask for private keys, seed phrases or passwords.

Sources

Test your wallet extension's release path

Guardian tests what a bad update to your extension could reach, from key storage at unlock to who can publish to the store.