Trust Wallet Chrome Extension Breach Drains $7M via Malicious Code

• A malicious update in Trust Wallet’s Chrome extension v2.68 led to roughly $7 million in crypto stolen.
• The injected code exfiltrated users’ seed phrases to an attacker-controlled server api.metrics trustwallet.com, triggering immediate drains on Bitcoin, Ethereum, Solana wallets.
• Hundreds of wallets across multiple chains were drained on Dec 24–25. Funds were laundered via ChangeNOW, KuCoin, FixedFloat and bridges.
• Trust Wallet, a Binance owned non custodial wallet confirmed the incident, urging all users to disable v2.68 and upgrade to v2.69. They pledged to refund victims.
• This is a supply chain compromise of a trusted extension. Defenders should treat browser wallets like untrusted software: verify updates, monitor analytics traffic, and block known malicious domains.

Late on Dec 24, 2025, Trust Wallet a popular multi chain crypto wallet owned by Binance released version 2.68 of its Chrome browser extension. Within hours, users began reporting unexplained fund drains. By Dec 26 Trust Wallet publicly acknowledged a security incident with v2.68 and said about $7 million was impacted. In its advisory, the company urged every Chrome extension user to disable v2.68 and immediately update to v2.69, which removes the malicious code=. This breach matters because it demonstrates how attackers can weaponize trusted update channels, a form of supply chain attack to compromise self custody wallets. Corporate security teams especially those responsible for endpoint and application security should treat this as a fresh wake up call about extension and update chain integrity.

What Happened?

On Dec 24, Trust Wallet quietly published Chrome extension v2.68. Soon afterward, multiple users reported that funds disappeared from wallets imported into that extension. On Dec 25 blockchain researcher @ZachXBT sounded the alarm: Hundreds of Trust Wallet wallets have been hacked in the last 2 hours on the @TrustWallet Chrome extension. Social media feeds showed victims from various blockchains, raising suspicion of a coordinated issue.

Over the following day it became clear the breach was isolated to extension v2.68. Trust Wallet confirmed on Dec 25 that a security incident affected version 2.68 only, advising users to disable it immediately and install version 2.69 as a fix. By Dec 26, the company estimated ~$7M had been stolen and promised to refund affected users. In statements, Trust Wallet emphasized mobile apps and other extension versions were not impacted. Co founder Changpeng Zhao CZ of Binance later tweeted that user funds were SAFU safe and Trust Wallet would cover all losses.

Security teams had to piece together the timeline from on chain evidence and community analysis. Researchers identified that v2.68 contained a backdoor: it was essentially a supply chain compromise of the extension code itself. The malicious code began exfiltrating data to a domain metrics trustwallet[.]com first seen on Dec 21 as soon as the compromised version was released. Within a couple of days the domain was taken offline, but not before many victims were hit. Trust Wallet’s official channels later confirmed the incident and instructed everyone to update their extensions. Official advisories urged no interaction with unverified messages or sites claiming to fix the issue, a wise caution given attackers immediately launched phishing sites around this event.

Technical Details How the Attack Works

The attack was executed by injecting stealthy JavaScript into the Trust Wallet extension package. Security researchers found that version 2.68 contained hidden code in a bundled file e.g. 4482.js which only ran under certain conditions. In essence, the payload worked as follows:

• Trigger on seed import/unlock: When a user unlocked a wallet or imported a seed phrase into the extension, the malicious code activated. It looped through all wallets stored in the extension and called the GET_SEED_PHRASE function for each one. Trust Wallet supports unlocking by password or passkey, which the code also intercepted.
• Decrypting the mnemonic: Using the user’s password or passkey, the backdoor code decrypted the retrieved seed phrase in memory.
• Exfiltration via analytics: The decrypted seed phrase was then wrapped into an HTTP request and sent off to the attacker controlled server api.metrics trustwallet[.]com. To avoid raising suspicion, the code masqueraded this as analytics traffic. It reused the legitimate PostHog JS analytics library bundled with the extension, merely redirecting its endpoint to a bogus domain. In short, attacker code directly tampered with Trust Wallet’s own codebase and exploited a trusted analytics channel to siphon secrets.
• Domain registration: The domain metrics trustwallet.com had been registered on Dec 8, 2025, just weeks before the attack. First recorded contacts from the extension to api.metrics trustwallet.com appeared on Dec 21. This timing suggests the attacker may have had deployment access days in advance. Notably, security firm SlowMist concluded that this was likely a professional, APT level supply chain breach perhaps via compromised developer devices or build credentials.
• Laundering the loot: Once seed phrases were stolen, the attackers promptly emptied the wallets. Blockchain investigators tracked the stolen funds being swapped and sent through centralized exchanges and cross chain bridges. For example, analyses show ~33 BTC ~$3M drained, ~$3M in Ethereum, and some Solana, all moved on Dec 25–26. A large chunk was laundered through services like ChangeNOW, FixedFloat, KuCoin and HTX.

Importantly, this attack had nothing to do with breaking cryptographic keys or blockchain protocols. Instead it subverted the client environment: the victim effectively gave up their own seed phrase to the attacker. As one report notes, self custody failures do not always require breaking cryptography. In this case the trust chain of the software update was broken.

Who Is Affected?

The compromise is specific to Trust Wallet’s Chrome extension version 2.68. That was a recent release dated Dec 24, 2025; any desktop users who upgraded to v2.68 were at risk. Trust Wallet has about 1 million Chrome extension users listed on the Web Store, though not all import their mnemonic into the extension. Only users who imported a seed phrase or wallet into the v2.68 extension were vulnerable, since the malicious code required a wallet present and unlocked.

Importantly, mobile app users iOS/Android and users of older or other versions of the extension were not affected. Trust Wallet clarified that the flaw was limited to the extension’s internal code for v2.68 and did not impact any server side or blockchain components. In practice, the victims appear to be retail users who self custody funds via the browser extension often interacting with DeFi sites, NFT platforms, etc.. Geographically the impact is global any Trust Wallet user running the compromised extension was exposed.

Because the code triggered on seed import, even users who only just set up the extension or briefly unlocked it could have lost funds. In short: if you ever installed that extension and entered a recovery phrase after mid Dec 2025, assume the worst. Trust Wallet has emphasized that all impacted users will be reimbursed, but defenders should still follow incident response best practices e.g. moving any remaining assets to fresh wallets.

Real World Impact

The direct impact has been severe and rapid. Over Dec 25–26, analysts tallied millions of dollars drained from hundreds of wallets. Blockchain forensics from ZackXBT, PeckShield, SlowMist, etc. report roughly 33 BTC ~$3M stolen, ~$3M in Ethereum, and some amount in Solana. Hundreds of Trust Wallet users reported unexpected balance drops; one user alone posted a $700k loss. By the end of the first day, analysts estimated total losses at over $6–7 million.

The stolen crypto was quickly funneled into mixed channels. Public data shows the attacker sending the bulk of funds to services like ChangeNOW, FixedFloat, KuCoin and HTX for conversion. For example, PeckShield noted >$4M went to these CEXs and a few bridged addresses within 24 hours. Notably, the attackers also spun up a phishing campaign concurrently. Security researchers observed scam websites such as fix trustwallet[.]com impersonating Trust Wallet to trick more victims into giving up their seed phrases. These sites asked users to update and submit their mnemonic, but were pure traps.

As of writing, hundreds of Trust Wallet users have filed theft reports. Trust Wallet’s CEO says TrustWallet will cover losses, and is working on refunds. Still, the event has shaken confidence in extension security. Even though no crypto protocol itself was broken, the net effect is akin to a mass wallet hack. For affected organizations e.g. funds held by employees, or corporate dev accounts in Trust Wallet, the losses and recovery process can be substantial. Importantly, this incident generated a deluge of support requests and remediation efforts on Christmas Day, a clear sign that attackers timed this for maximum disruption.

Why This Matters to Defenders

This breach is a textbook supply chain compromise in the crypto domain. It shows that adversaries will target the weakest link in the transaction flow in this case, the wallet software rather than trying to exploit the blockchain itself. For security teams, there are several lessons:

• Trusted channels can be subverted. The attackers inserted malicious code into an official update of Trust Wallet. This means any system that automatically applies updates or lacks validation of update contents can be vulnerable. It underlines the need for end to end integrity checks code signing, reproducible builds, in tree versus external libraries. SlowMist’s analysis emphasizes that the attacker directly tampered with the application’s own code…using the legitimate PostHog library as the exfiltration channel.. In other words, defenders must assume that update pipelines and developer environments can be targeted by nation state or APT level actors.
• The user environment is critical. Even though Trust Wallet’s cryptography was sound, users lost funds because the local environment of the browser extension was compromised. As one summary puts it, even when a wallet’s core cryptography remains secure, compromising the environment in which keys are handled can be sufficient to drain funds.. This parallels other cases where malicious browser extensions or USB implant malware, etc. quietly steal credentials. Defenders should extend their threat model to include software supply chains and endpoint malware as top risks for crypto assets.
• Seed phrases are highly sensitive. The attack only needed users’ seed phrases, arguably the single most critical secret in crypto. Because the extension asked users to enter their seed to import wallets, the attacker could steal it. This underscores a broader issue: requiring users to paste seeds into hot software is a high risk pattern. Organizations should educate users to never reuse old seeds, and should consider additional controls e.g. hardware keys or threshold wallets for large holdings. The incident is part of a larger pattern of credential stealing malware, where an unassuming interface like an analytics popup can harvest private keys. For background on this class of threats, see earlier analyses of credential stealing wallet attacks.
• Supply chain and insider threat. Trust Wallet hinted the breach could be an insider or developer device compromise. The fact the malicious code came from within the extension’s codebase not a third party library is particularly alarming. It aligns with recent industry trends: high profile incidents from SolarWinds to Codecov have shown attackers penetrating build servers or stealing signing keys. Security teams in crypto firms and beyond should therefore audit their DevOps processes and restrict who can publish new builds.
• Rapid detection is vital. In this case, community analysts spotted suspicious transactions and unauthorized URLs within hours. Defenders should have monitoring in place for unusual outgoing connections e.g. from browser processes and for known malicious domains. In a corporate setting, intrusion detection systems IDS could flag outbound traffic to domains like metrics trustwallet.com or fix trustwallet.com. The moment a new update rolls out, QA or internal scanners should verify the new code against known good baselines to catch unexpected changes.

In sum, this incident highlights that any software update can be weaponized. CISOs and SOC teams should treat high privilege client software like wallets, VPNs, productivity tools, etc. as potential attack vectors, just as they would an on prem network appliance or cloud service. As supply chain attacks continue rising across industries, organizations should review their update policies, privileges, and monitoring. For example, see our related coverage on software supply chain threats and malicious extension incidents to understand how these risks are manifesting more broadly.

Mitigation & Defensive Actions

• Update and patch: Immediately ensure all Trust Wallet Chrome extensions are upgraded to v2.69 from the official Chrome Web Store and disable or uninstall v2.68. In enterprise environments, push this change via group policy or endpoint management to prevent the rogue version from running. Verify the extension ID (egjidjbpglichdondbcbdnbeeppgdph) matches Trust Wallet’s official listing.
• Remove and recover: Any user who installed v2.68 should assume their wallet seeds were compromised. As a precaution, disconnect that machine from the network before investigating. Export the wallet’s private keys/seed phrase only after going offline! and then remove the extension. Generate a new wallet on a secure, isolated device and move all funds there, treating the old seed as permanently unsafe. If this was done for an institutional wallet, coordinate with legal/compliance for reporting any breach of critical credentials.
• Block malicious domains: Add the domains api.metrics trustwallet.com and fix trustwallet.com to your organization’s DNS or firewall blocklists. The metrics domain was used to exfiltrate seeds, and fix trustwallet.com was a phishing site offering a fake patch. WHOIS data links them to the same attacker. Also monitor for any new variants like support trustwallet or similar. If your SIEM can inspect HTTPS SNI or IPs, flag any connections from trusted clients to these names.
• Monitor extensions: Implement browser controls to prevent unauthorized extensions. In Chrome Enterprise, for example, only allow whitelisted extensions. Audit your environment for any unexpected or outdated wallet extensions. Consider enabling third party cookies or restricting cross origin calls if possible. For detection, check browser logs for calls to unfamiliar analytics endpoints. The use of legitimate analytics libraries PostHog here shows that even built-in scripts can be subverted, so extreme caution is warranted.
• Review privileged processes: Investigate whether any internal systems may have been used to inject this malicious code e.g. CI/CD pipelines, code repositories, or developer accounts. Rotate any API keys or credentials associated with building/deploying the extension. If this is deemed an insider or supply chain attack, emphasize defense in depth so that no single credential compromise can push malicious code.
• Train users: Alert all stakeholders about the incident. Remind users never to import seed phrases into unknown sites. Emphasize that official support will not ask for private keys or recovery phrases. Warn them of phishing attempts: attackers often send urgent messages e.g. browser extension hacked fix here that lead to fake sites. The Trust Wallet team specifically told users to ignore any instructions not from official channels. Encouraging a culture of skepticism toward unsolicited crypto support messages can prevent similar scams.

These steps focus on this specific breach, but also strengthen general posture. The core mitigation is simply: trust, but verify all updates and treat every Chrome extension as potentially risky. For related guidance, see our coverage on enterprise browser security best practices and supply chain attack defenses.

Related Threat Trends

This incident is part of a broader rise in software supply chain and extension based attacks. In recent years we’ve seen malicious updates in package repositories and even Trojanized firmware. In the cryptocurrency space, similar supply chain tactics have shown up for example, attackers have pushed fake wallet apps or library updates to harvest private keys. Attacks on hot wallets and extensions are particularly popular because they can yank funds without touching blockchain security.

While this Trust Wallet hack isn’t a classic ransomware, it follows the same playbook of exploiting trusted code paths. Security analysts note that many incidents like this and others are not due to cryptographic flaws, but to compromised operating environments. Defenders often focus on patching OS or network vulnerabilities, but here the risk was in userland. The use of a legitimate analytics framework PostHog as a covert channel also mirrors techniques seen in advanced persistent threats on enterprise networks.

For blockchains and wallets, the trend is clear: adversaries shift to attacking human and software habits, seed import, auto updates rather than crypto math. This echoes other threat patterns we cover on CyberTrustLog, such as malicious browser extensions that steal login creds, or off chain routes to launder crypto using centralized exchanges quickly after theft. It also underlines the need for cross discipline vigilance: blockchain investigators, cybersecurity teams, and software supply chain auditors must work together. For comparison, earlier research has looked at phishing scams targeting wallet users and large scale scam campaigns exploiting DeFi interfaces.

In summary, the Trust Wallet breach is a high profile example of supply chain risk manifesting in the crypto world. It reinforces the industry’s recent push toward securing software provenance and educating users on self custody hazards. Security teams should track this alongside other trends like ransomware supply chain pivots and malicious open source libraries, as they all share the same core lesson: trust no code blindly.

The Trust Wallet Chrome extension incident is a stark reminder that security is only as strong as the weakest link in the chain. A single malicious update in a popular wallet extension was enough to drain millions from unsuspecting users. By rapidly identifying the breach, Trust Wallet and the community limited further impact, and the company has promised to reimburse losses. However, the technical analysis exposes systemic vulnerabilities: attackers can hijack legitimate update mechanisms and hide inside benign looking code.

For defenders, the path forward is clear but challenging. Enforce stricter controls on code updates, monitor for unusual analytics or network traffic, and educate users on safe self custody practices. The forensic details of this breach such as the metrics trustwallet.com endpoint offer new IoCs, but the broader message is perennial: validate every component in your security stack, because even trusted interfaces can turn malicious. As the crypto ecosystem matures, incidents like this will undoubtedly shape tighter operational protocols from developer hygiene to incident response planning.

About the Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike and the owner of CyberTrustLog.com. Specializing in advanced penetration testing and offensive security operations, he holds certifications including CISSP, OSCP, and OSWE. Mohammed has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors