Trust Wallet has urged users of its Chrome browser extension to treat version 2.68 as compromised after researchers found a hidden script that exfiltrates wallet secrets and attackers drained at least $6 million, with the team now confirming about $7 million in impact and promising refunds.
What Trust Wallet confirmed
On December 25, Trust Wallet acknowledged a “security incident” in its browser extension and warned that it affects Trust Wallet Browser Extension version 2.68 only. In an alert posted on X, the team told users with 2.68 installed to disable the extension and upgrade to 2.69 through the official Chrome Web Store listing, while stressing that mobile-only users are not impacted. You can see that advisory on the project’s official account at @TrustWallet and in a follow-up thread at this post.
The Chrome Web Store entry for Trust Wallet now shows version 2.69 as the current build, updated on December 25, 2025, with around 1,000,000 users. That listing sits at chromewebstore.google.com/detail/trust-wallet/egjidjbpglichdcondbcbdnbeeppgdph and confirms the patched version number.
On December 26, Trust Wallet followed up again on X, stating that the incident impacted “approximately $7 million” and that the team will refund affected users. That refund statement appears on the official account at this post and directs victims to work with support through twtholders.trustwallet.com, the company’s established help center.
How the exploit works
The vulnerability ties directly to a specific Chrome extension build. Trust Wallet pushed version 2.68 on December 24. Within hours, users who interacted with the browser extension began to report sudden wallet drains across Bitcoin, EVM chains and Solana.
Security researcher Akinator inspected the extension bundle and highlighted suspicious logic in a packed JavaScript file labeled 4482.js. In an X thread at @0xakinator, he described code that masquerades as analytics but silently sends wallet data to an external endpoint at api.metrics-trustwallet[.]com, tied to the newly registered domain metrics-trustwallet[.]com. BleepingComputer reviewed this analysis and published screenshots of network traces that show mnemonic data leaving the extension when a seed phrase is imported, along with the bundled script reference. Their writeup is here: Trust Wallet confirms extension hack led to $7 million crypto theft.
Security researcher Andrew Mohawk initially questioned the claims, then confirmed the exfiltration path in his own inspection of browser requests. He documented those findings on X at @AndrewMohawk, again pointing to traffic that sends seed phrase data toward the rogue metrics domain after import.
This behavior draws a tight boundary around the riskiest action. Current public analysis links the most severe drains to users who imported or entered a seed phrase while running extension v2.68. Updating to 2.69 removes the malicious logic from the extension bundle. It does not restore secrecy to a seed phrase that already passed through the compromised version.
Loss estimates and CZ’s refund pledge
On December 25, on-chain investigator ZachXBT reported that he had received messages from hundreds of affected users and estimated losses at more than $6 million, spread across multiple blockchains. His early tallies and address clusters circulated through multiple outlets and sparked broader scrutiny of the 2.68 rollout.
By December 26, BleepingComputer and other security outlets framed the incident as a browser extension supply chain compromise that sits in the $6 million to $7 million range, based on visible outflows and victim reports. The exact loss figure still tracks victim discovery and on-chain consolidation, so the upper bound can move as more addresses link into the cluster.
Binance founder and Trust Wallet owner Changpeng “CZ” Zhao stepped in publicly and committed to make users whole. In an X post at @cz_binance, he wrote that about $7 million had been affected and that Trust Wallet will cover those losses.
“So far, $7m affected by this hack. TrustWallet will cover. User funds are SAFU.”
That pledge sets expectations for reimbursements alongside Trust Wallet’s own December 26 statement that it will refund all impacted users and is refining the refund process.
Despite the hack, Trust Wallet Token (TWT) held up relatively well. At press time, TWT traded around $0.83 with a 24-hour move of roughly +1.9% and daily volume near $34 million, according to CoinMarketCap. CryptoSlate’s own price checks earlier in the day showed similar levels. The market priced in the exploit and refund commitment as a serious hit to operational security, not a collapse in the underlying project.
Phishing domains piggyback on the chaos
Attackers did not stop at the compromised extension. While Trust Wallet and researchers warned users, BleepingComputer and other trackers observed phishing domains that targeted the same audience. One domain, fix-trustwallet[.]com, impersonated an official remediation page and invited users to “update” their wallet. The fake page then prompted visitors to enter their seed phrase, which would have handed full control of their funds to scammers.
The metrics-trustwallet and fix-trustwallet domains share timing and registration traits. Security teams treat them as part of the same threat actor cluster until stronger attribution emerges. For users who already face losses from the extension itself, this second wave adds another path to further damage.
Who is at risk and what to do now
Based on Trust Wallet’s statements and independent technical analysis, the current scope looks tight in version and broad in chain coverage.
- Impacted component: Trust Wallet Browser Extension for Chrome, version 2.68.
- Reported activity: unauthorized drains across EVM networks, Bitcoin and Solana after extension use.
- Highest-risk user action: importing or entering a seed phrase while running v2.68.
- Reportedly not impacted: mobile-only users and other extension versions, according to Trust Wallet’s X guidance.
Trust Wallet’s step-by-step instructions on X and in mirrored coverage all point to the same immediate playbook for Chrome users:
- Do not open the Trust Wallet extension if it still runs version 2.68.
- Open Chrome’s extension management page for Trust Wallet at
chrome://extensions/?id=egjidjbpglichdcondbcbdnbeeppgdph, or reach it via the official listing at the Chrome Web Store. - Toggle the extension off, enable Developer Mode, hit “Update,” then confirm that the installed version shows 2.69.
- If you ever imported a seed phrase while 2.68 was present, treat that seed as compromised, migrate funds to a new wallet created with a fresh seed phrase, and review token approvals on every chain that wallet touched.
- Contact Trust Wallet support through twtholders.trustwallet.com, not through links in DMs or search ads.
For users who rely on the extension for active DeFi positions, this response carries operational friction. Rotating wallets and re-establishing approvals across multiple chains costs time and gas. Given the confirmed presence of a key-harvesting script, researchers and incident responders treat this cost as the safer side of the trade.
Browser extensions under renewed scrutiny
This incident hits a fragile junction between convenience and key custody. Browser wallets sit inside a general-purpose browser, inherit its attack surface, and depend on the integrity of the distribution channel. When a malicious update reaches the Chrome Web Store, as happened here, standard user hygiene cannot block the compromise.
CryptoSlate’s coverage of the hack connects it to new academic work on malicious Chrome extensions, including a September 2025 paper on supervised machine-learning detection in the Chrome Web Store, hosted at arXiv:2509.21590. That research shows how detection quality drifts as attacker behavior evolves. The Trust Wallet 2.68 episode puts a practical face on that concept for crypto users.
Trust Wallet now has three parallel jobs. It must ship tight refunds to restore user confidence, deliver a credible root-cause report that explains how the malicious code entered the extension build, and prove that its build and release pipeline can resist similar tampering in the future. Until then, the safest assumption for any seed phrase that ever touched v2.68 is simple. Treat it as burned.
