Trust Wallet Browser Extension Poisoned via Shai-Hulud NPM Attack, $8.5M in Crypto Drained from 2,596 Users

Summarize with:



Can wallet developers escape the supply chain? Trust Wallet, serving 200 million users, discovered that leaked GitHub developer secrets enabled attackers to compromise its Chrome extension, drain $8.5 million in crypto assets from 2,596 wallets, and expose the vulnerability pathway that attackers now use across the industry. The attack traced directly to Shai-Hulud 2.0, an NPM registry compromise that harvested 400,000+ developer credentials—showing how a single compromised package repository can liquidate entire ecosystems of trust.

Breach timeline: December 24, 2025 (incident date). Trust Wallet’s GitHub developer secrets were exposed during the Shai-Hulud 2.0 campaign, which ran from August through November 2025. The attack granted threat actors direct access to Trust Wallet’s browser extension source code and Chrome Web Store (CWS) API key. Using this CWS API key, attackers uploaded a malicious version 2.68.0 of Trust Wallet’s Chrome extension without requiring internal approval or manual code review—bypassing the company’s standard release security controls.

What the attacker accessed: The compromised GitHub credentials provided full access to (1) Trust Wallet’s private source code repository, (2) the Chrome Web Store release API, (3) internal build and deployment workflows, and (4) cryptographic signing keys. With CWS API access, the attacker published a trojanized version of the wallet extension that included embedded malicious JavaScript. The modified extension collected sensitive user wallet data (private keys, recovery phrases, transaction confirmations) and exfiltrated it to attacker-controlled domains registered as metrics-trustwallet.com and api.metrics-trustwallet.com. The fake domain names mimicked legitimate Trust Wallet infrastructure, evading user suspicion.

User impact: 2,596 cryptocurrency wallets were drained of approximately $8.5 million in assets (updated from initial $7 million estimate). Over 200 million Trust Wallet users were at risk during the window where the compromised extension was available. The Chrome Web Store auto-released version 2.68.0 without human intervention after passing automated vetting, meaning the malicious code was live and installing on user systems before Trust Wallet security teams detected the compromise.

Direct financial loss multiplied by precedent: $8.5 million stolen from 2,596 wallets demonstrates that supply chain attacks against wallet infrastructure now have direct liquidation value. Attackers no longer need to compromise end users individually—they compromise the developer credentials that manage the tools users trust. Every update users install becomes a potential attack vector.

Ecosystem compromise expanded scope: The Shai-Hulud campaign didn’t stop at Trust Wallet. It exposed 400,000+ raw developer secrets across 27,000+ malicious NPM packages, with over 60% of stolen NPM tokens still valid as of December 1st. Any developer who installed one of those packages leaked credentials to GitHub repositories, CI/CD pipelines, AWS/Azure cloud infrastructure, and production deployment systems. Teams using those credentials continued normal operations, unaware attackers had observer access to their infrastructure.

Wallet users have no recourse detection: Users who installed the compromised version 2.68.0 had no way to know their wallets were being drained in real-time. The malicious JavaScript ran silently, exfiltrating private key data to attacker infrastructure. By the time users noticed missing funds, the transactions were already confirmed on the blockchain—irreversible and untraceable to a legitimate service failure.

Developer trust model failed at scale: Trust Wallet’s release process relied on internal GitHub credential security and the assumption that API key holders had legitimate intent. Compromised credentials bypassed both. The Chrome Web Store’s automated review process, designed to protect users, enabled the attack by releasing code without human security review when credentials were valid. Security controls intended to prevent insider threats became attack enablers when external parties possessed leaked credentials.

Lateral attack vector established: With access to Trust Wallet’s internal repositories and CI/CD systems, attackers gained reconnaissance data on system architecture, dependencies, infrastructure, and personnel. Follow-on supply chain attacks against the vendors and partners Trust Wallet integrates with are now probable—each with harvested credentials that pass authentication checks.

Supply chain attack vector: The Shai-Hulud campaign established a self-propagating method for harvesting developer credentials. When developers installed malicious NPM packages, the packages automatically exfiltrated CI/CD tokens, GitHub personal access tokens, AWS keys, npm registry tokens, and Slack/Discord credentials. Extracted credentials were then published to attacker-controlled GitHub repositories, creating a shared database of valid authentication tokens across thousands of companies.

How Trust Wallet became a target: Attackers scanned the exposed credentials database and identified valid GitHub and CWS API tokens belonging to Trust Wallet developers or automated deployment systems. Rather than conduct traditional reconnaissance (phishing, exploiting zero-days), attackers simply used leaked tokens to authenticate as legitimate users to Trust Wallet’s infrastructure. The CWS API key bypassed Chrome Web Store’s origin verification because it presented as an authorized publisher signing legitimate releases.

Malicious extension deployment: Using the CWS API key, attackers fetched the legitimate source code from GitHub, inserted malicious JavaScript code that collected wallet recovery phrases and private keys on user interaction, and re-signed the extension with the stolen key. The modified version 2.68.0 was uploaded to Chrome Web Store, which automatically published it after scanning for known malware signatures. The malicious code was syntactically valid and didn’t match signature patterns of known threats, so it passed automated checks.

Data exfiltration to fake infrastructure: The malicious JavaScript in the wallet extension sent collected user data to metrics-trustwallet.com and api.metrics-trustwallet.com—domains registered by the attacker and hosted on attacker infrastructure. Users connecting to these fake domains from within the compromised extension trusted the data path because it came from their “official” wallet app. Transaction authorization requests, private key metadata, and seed phrases were exfiltrated to attacker systems and exploited for immediate fund transfers.

Why existing security failed: Automated code review systems focused on detecting known malware signatures and exploit patterns. The malicious JavaScript was written as legitimate wallet functionality, just with exfiltration endpoints pointing to attacker infrastructure. Manual code review by Security or compliance personnel would have caught the change, but the CWS API key bypass eliminated that step. The Chrome Web Store’s assumption that API key holders always operate legitimately proved false when credentials were leaked via supply chain attack.

Shai-Hulud origins: The campaign began in September 2025 with a self-propagating attack on the npm registry. Initial malicious packages included code that (1) installed the TruffleHog secret scanning tool, (2) ran TruffleHog to extract secrets from the developer’s local file system and Git history, and (3) exfiltrated those secrets to attacker infrastructure. The self-propagating element meant that developers who installed one malicious package became vectors for spreading compromised packages to their own dependencies and collaborators.

Expansion to Shai-Hulud 2.0 (November 2025): The campaign evolved to add 27,000+ additional malicious packages to npm, all executing similar credential harvesting logic. Developers working on popular open-source projects or in enterprise environments installed these packages as transitive dependencies—unknowingly adding malware to their supply chains. Over 800 legitimate packages were touched by Shai-Hulud malware, exposing 400,000+ secrets: GitHub personal access tokens, npm registry tokens, AWS access keys, Azure credentials, CI/CD pipeline secrets, and database connection strings.

Credential database as attack infrastructure: Rather than exploit individual targets sequentially, attackers accumulated the leaked credentials into a searchable database organized by organization name, secret type, and access level. Organizations like Trust Wallet became visible in this database because their GitHub tokens appeared in the published GitHub repositories (attackers auto-committed leaked secrets to test accounts). Attackers queried the database for tokens belonging to cryptocurrency wallet companies, payment processors, and financial infrastructure.

Why CWS API key was critical: Chrome Web Store API keys are long-lived credentials that enable automated build systems to publish updates without human intervention. If a developer’s GitHub account is compromised, an attacker must still convince Chrome Web Store that the update is legitimate—typically requiring manual review and approval steps. If an API key is compromised, attackers bypass this human checkpoint entirely. The leaked CWS API key meant attackers could upload any code revision directly, and Chrome Web Store’s automated systems would publish it as a legitimate release from a trusted vendor.

Why the attack remained undetected initially: Trust Wallet’s source control didn’t immediately flag the leaked GitHub credentials because the credentials weren’t used through normal web login—they were used via API calls that appeared as legitimate automated system activity. Chrome Web Store API uploads from the leaked key appeared in audit logs as normal developer activity. The malicious extension code passed static analysis because malware detection tools don’t flag wallet data exfiltration to fake domains as suspicious if the code otherwise functions as a legitimate wallet app.

Primary source: BleepingComputer January 2, 2026 reporting Trust Wallet’s official statement linking the $8.5M theft to Shai-Hulud NPM supply chain compromise.

Secondary reporting on Shai-Hulud: Shai-Hulud 2.0 detailed analysis (BleepingComputer) documenting 400,000+ exposed secrets across 27,000+ malicious packages and 800+ legitimate packages touched.

Trust Wallet’s incident statement: Trust Wallet published a community update confirming developer GitHub secrets exposure, CWS API key compromise, and the $8.5M user fund loss. The company stated it revoked all release APIs, suspended malicious domains, and began reimbursing affected users.

Indicators of Compromise (IoCs) for defenders: Organizations should monitor for (1) unusual Chrome Web Store extension uploads using API keys, (2) version numbers appearing in extension updates without corresponding internal release approvals, (3) npm packages with sudden dependency additions or modified install scripts, (4) Git commits to private repositories from unfamiliar IP addresses or automation accounts, (5) exfiltration of secrets to external domains during npm package installation, (6) Chrome extensions connecting to domains other than official vendor infrastructure.

Defensive actions for wallet users and organizations: Cryptocurrency wallet users should (1) verify extension versions in Chrome Web Store, (2) rotate wallet seed phrases if they used Trust Wallet v2.68.0 between December 24-26, (3) enable additional authentication on exchange accounts and wallet custodians, (4) monitor blockchain transactions for unauthorized activity. Developer organizations should (1) audit npm package.json dependencies for known malicious packages from Shai-Hulud campaign, (2) rotate all GitHub personal access tokens and npm registry tokens, (3) conduct credential sweep of CI/CD systems, AWS/Azure accounts, and production databases, (4) require human code review approval even for API-authenticated releases, (5) implement namespace verification so extension domains match official vendor domains.