TL;DR

• A Chrome extension posing as TronLink uses MV3 APIs to harvest wallet seed phrases and login credentials.
• The extension passed Chrome Web Store review by mimicking a legitimate, widely-used crypto wallet.
• MV3's stricter content security policy did not prevent the credential-theft technique used here.

Malicious Chrome MV3 extension impersonates TronLink to steal crypto wallet credentials

What happened

Researchers at CyberSecurityNews published findings on May 13, 2026, detailing a malicious Chrome extension built to impersonate TronLink, a legitimate and widely-installed TRON blockchain wallet with millions of users. The fake extension was constructed under Manifest V3, Chrome's current extension platform standard, and made it into the Chrome Web Store by closely replicating TronLink's name, icon, and UI.

Once installed, the extension intercepts wallet credentials at the point of entry. When a user types their seed phrase or password into what appears to be the standard TronLink interface, the extension captures that input and exfiltrates it to an attacker-controlled server. The attack doesn't require any browser exploit. It simply presents a convincing fake UI and reads what the user types.

The extension also injects content scripts into web pages to monitor for wallet-related activity, expanding its collection surface beyond the extension popup itself. According to the CyberSecurityNews report, the malware targets both seed phrases and plaintext passwords, giving attackers multiple paths to full wallet access.

Source: CyberSecurityNews, May 13 2026

Why MV3 didn't stop this

Manifest V3 was introduced partly to reduce extension abuse. It eliminated persistent background pages in favor of service workers, restricted the use of remotely hosted code, and tightened content security policy defaults. Google's stated rationale included making extensions more auditable and harder to weaponize.

This attack demonstrates the limits of those mitigations. MV3 prevents certain categories of abuse, particularly extensions that pull in obfuscated remote scripts at runtime, but it doesn't prevent an extension from rendering its own UI and reading form inputs. A malicious extension that ships all its logic locally, follows the MV3 API surface, and presents a plausible interface can still pass automated review and fool users.

The credential-theft technique here is conceptually simple: the extension owns its popup DOM entirely. Nothing in the Chrome security model prevents an extension from logging keystrokes inside its own popup or fabricating a wallet interface pixel-for-pixel. MV3's service-worker model changes the lifecycle of background logic, but it doesn't sandbox extension UIs from the extension's own scripts.

This is a known gap. Chrome Web Store policy prohibits deceptive extensions, but policy enforcement relies on review processes that attackers actively probe for weaknesses.

How the impersonation gets past review

Chrome Web Store review combines automated scanning with some manual checks. Attackers targeting high-value impersonation scenarios, like crypto wallets, have learned to time submissions, use clean metadata, and front-load benign behavior that only activates under certain conditions or after a delay.

In this case, the extension mirrored TronLink's legitimate listing closely enough to appear credible to users searching the store. Users who find an extension by searching a wallet name, rather than following a direct link from the wallet's official site, are particularly exposed. The store's search results don't always surface the verified original above a well-optimized fake.

Google has a "verified" badge program for some publishers, but coverage is uneven, and many users don't know to look for it.

What this means for extension developers and users

For developers building legitimate extensions, this incident carries a few concrete implications.

First, if your extension has significant brand recognition, someone may eventually clone it. Registering your publisher account, keeping your Chrome Web Store listing verified, and publishing your official extension URL prominently on your own domain are the most reliable ways to direct users to the real thing. Some developers now include a "verify you're using the official extension" check that pings their own domain and displays the result inside the extension UI.

Second, the use of MV3 by the attackers is worth noting. The assumption that MV3 extensions are inherently safer than MV2 ones is not well-founded. MV3 raises the floor on certain abuse vectors, but sophisticated attackers have adapted. Developers and security teams shouldn't treat MV3 compliance as a trust signal on its own.

For users, the practical advice is unchanged but worth repeating: install extensions only from links on the official product's website, not from store search results alone. Check the publisher name carefully. Wallet software in particular should be treated with the same caution as any financial application.

The broader pattern

This isn't the first time a crypto wallet extension has been cloned for credential theft, and the MV3 angle is new mainly in that it shows attackers have fully migrated their tooling to the current platform. Earlier waves of malicious wallet extensions were built on MV2. The underlying technique, a convincing fake UI that captures secrets at input time, predates both manifest versions.

Security researchers have documented similar campaigns targeting MetaMask, Phantom, and other wallets. The pattern is consistent: pick a wallet with a large user base, clone its UI, get into the store, and wait for installs. The TronLink impersonation follows the same playbook with updated technical packaging.

Chrome Web Store's response to reported malicious extensions has generally been removal within days of a credible report, but that window is enough to compromise a meaningful number of users, particularly given how quickly a well-ranked fake can accumulate installs.

For context, extension payment platforms like crxpay have noted that publisher identity verification at the monetization layer is one of the few points where developer identity gets independently checked, though that doesn't address the broader review gap for free extensions.

The CyberSecurityNews report is the primary source for the technical details summarized here. Independent verification of the specific extension's store listing and exfiltration infrastructure had not been published by other outlets at time of writing.