Trust Wallet Extension Backdoor: v2.68 Malicious Code Injection Analysis
Background
In the early hours of December 26, 2025 (Beijing time), @zachxbt reported on his channel that some Trust Wallet users found their funds drained. Shortly after, Trust Wallet’s official X account confirmed that version 2.68 of the Trust Wallet Browser Extension had a security issue, urging all users to immediately disable that version and upgrade to 2.69.

Upon receiving the intelligence, the SlowMist Security Team immediately began analyzing the relevant sample.
Code Diff
Let’s start by comparing the core code between the previously released v2.67 and the compromised v2.68:


Running a diff between the two versions reveals the malicious code the attacker injected:

Malicious Code
The backdoored code iterates through every wallet in the extension. For each wallet, it initiates a request to retrieve the encrypted seed phrase. It then decrypts the seed phrase using the password or passkeyPassword that the user entered when unlocking the wallet. If decryption succeeds, the seed phrase is sent directly to the attacker’s server.

Domain Analysis
A quick look at the attacker’s domain registration:

The malicious domain metrics-trustwallet[.]com was registered on December 8, 2025 at 02:28:18, through NICENIC INTERNATIONAL.
The first recorded request to api.metrics-trustwallet[.]com appeared on December 21, 2025:

This timeline aligns closely with the code backdoor being inserted around December 22.
Attack Reproduction
We traced the code further to reproduce the full attack chain.
Dynamic analysis shows that after the wallet is unlocked, the attacker populates the seed phrase into an error field visible in the R1 debugger:

This error data originates from the GET_SEED_PHRASE function call. Trust Wallet currently supports two unlock methods: password and passkeyPassword. The attacker captures whichever the user provides during unlock, then calls GET_SEED_PHRASE to retrieve the wallet’s seed phrase (and the private key works the same way), packing everything into an errorMessage field.

Here’s the code showing how emit calls GetSeedPhrase to grab the seed phrase and stuff it into the error object:

Traffic analysis through BurpSuite confirms that after obtaining the seed phrase, it is wrapped in the errorMessage field of the request body and sent to the attacker’s server at https://api[.]metrics-trustwallet[.]com, consistent with our earlier analysis:

After this flow completes, the seed phrase and private key have been compromised. The attacker’s familiarity with the extension’s internals is further evidenced by their choice to abuse the PostHog JS analytics SDK — a legitimate open-source platform for full-stack product analytics — as their data exfiltration channel.
My Assessment
This backdoor originated from a malicious source code modification within Trust Wallet’s own extension codebase (specifically targeting the analytics service logic), not from a compromised third-party package (such as a malicious npm dependency). The attacker directly tampered with the application’s own code, hijacking the legitimate PostHog library to redirect analytics data to an attacker-controlled server.
We have strong reason to believe this is a professional APT operation. The attacker may have already compromised a Trust Wallet developer’s device or deployment infrastructure well before December 8.
Remediation
- If you have installed the Trust Wallet Browser Extension, disconnect from the network immediately before any investigation or recovery.
- Export your private keys / seed phrases right away and uninstall the extension.
- Once your keys are backed up, migrate all funds to a different wallet as quickly as possible.