The Extension That Was Safe Last Month: How Browser Add-Ons Turn Into Wallet Stealers

The attack is not the download — it is the update

Almost everything written about malicious extensions assumes the danger is at installation: a fake listing, a typosquatted name, a suspicious developer. That advice is fine as far as it goes, and the campaigns documented through 2026 went around it entirely by attacking a moment nobody inspects.

Socket's threat research team documented a cluster of 40 malicious Firefox extensions, part of a wider set of 77 add-ons sharing source code and infrastructure, in a campaign they called the Offside Wallet Theft Factory and traced back to at least March 2026. The name comes from the tactic. Nine of the malicious identities did not start as crypto products at all. They first shipped as ordinary sports score extensions — football, basketball, NBA, hockey — and presented themselves that way. Later versions under the same Firefox IDs were repurposed into wallet-stealing extensions, so any install base and review history attached to those listings would have carried over (our inference; Socket does not report figures).

Sit with what that defeats. Install counts, reviews and developer history are signals about past behaviour. A repurposed listing keeps them while the code underneath changes, and none of them describes what the extension became. The researcher who led the analysis, Kirill Boychenko, framed the economics in a line worth remembering: a single successful installation can expose a recovery phrase, private key or wallet state worth far more than the cost of repeatedly publishing disposable extensions. When one hit pays for hundreds of failures, patience is cheap.

The same pattern showed up in the Chromium world. Socket researcher Karlo Zanki documented 19 extensions — 18 in Chrome, one in Edge — carrying a modular framework for wallet draining, and the highest-impact listing among them was not a crypto product either. It was a right-click-and-copy utility with roughly 80,000 combined installs. An add-on that does something small, useful and entirely unrelated to money is the ideal host, because nobody audits the thing that unlocks text selection on a stubborn web page.

What an extension can actually reach, and when you get warned

To understand why this works you have to be precise about what an extension is. It is not a separate app in a sandbox next to your browser. It is code that runs inside your pages, with whatever access its permissions describe, and the relevant permission is broader than most people realise when they click through it.

Mozilla's explanation of permission requests is candid about why the broad one exists: extensions ask to access your data for all websites because a web page can contain virtually anything, and some extensions need to read everything on it to do their job — ad blockers identifying ads, password managers finding form fields, shopping tools reading product details. These are legitimate needs. The same access, in different hands, means the extension can read every page you open and change what those pages do. Chrome's permissions reference states the consequence in its own warning text for privileged access: read and change all your data on all websites.

Read that against what a wallet interface is. It is a web page. A transaction confirmation is a rendered page. An address you paste is a form field. Code with permission to read and change all data on all sites is inside that boundary, not outside it, which is why an extension attack does not require you to make any visible mistake — there is no fake domain to notice and no bad link to avoid.

Now the mechanism that makes updates the ideal delivery route. Chrome's developer documentation on permission warnings explains that some permissions are less intrusive and do not display a warning, while others trigger a warning the user has to allow, and specifies the consequence: when a new permission that triggers a warning is added, the extension is disabled until the user accepts the new permission. That protection is real and worth knowing. But the inverse is equally true and much less discussed. If an update changes what the code does while staying inside the permissions you already granted, there is no prompt, no notification and no disabling. The extension simply becomes different software on your machine, at a moment of the developer's choosing rather than yours.

The two ways they take the money

The documented campaigns split cleanly into two techniques, and they call for different defences, so it is worth separating them.

The first is harvesting the secret. Here the extension presents a wallet interface — impersonating a known product, or offering a plausible reason to enter your phrase such as an import, a validation, a migration or a recovery — and captures what you type. In the Firefox campaign Socket documented the impersonated products by name: OKX, Rabby Wallet and TronLink. Fifteen of the extensions captured recovery phrases and private keys and exfiltrated them through Cloudflare Workers, while another seven used attacker-controlled Supabase projects as remote switches for phishing and decoy content — meaning the same installed extension could present innocent behaviour or its attack on command, which also defeats anyone testing it once and pronouncing it clean.

The defence against this one is a rule with no exceptions attached: your recovery phrase is entered exactly once, into your wallet, when you deliberately restore it, on a device you control. Never in response to a prompt that appeared. Never as a validation, a sync, an eligibility check, an unlock, an airdrop claim or a support step. The request is the attack — which is the same principle behind pre-filled recovery sheets shipped with counterfeit hardware devices, where a phrase you never chose is presented as though it were yours.

The second technique never asks you for anything. Thirteen extensions in the Firefox campaign shipped modified builds of Rabby Wallet, engineered to exfiltrate serialized keyrings before local encryption — that is, taking the key material at the point in the process where it is still readable, inside software that otherwise behaves exactly like the real wallet, because it largely is the real wallet. Five more focused on credentials and clipboard data through hard-coded command and control infrastructure. The Chrome and Edge cluster was broader still: a framework of sixteen modules covering multi-chain wallet draining, hardware-wallet seed-phrase harvesting, exchange and wallet account theft, universal credential and form grabbing, social account theft, browser history collection and ClickFix-style social engineering lures, with a loader that can rotate its command-and-control endpoint on instruction, spreading victims across multiple infrastructure groups to make detection harder.

Careful behaviour helps less against the second category, which is the uncomfortable part. Installing only from the vendor's own link avoids lookalike listings, but once a modified build is running there is no visible error to avoid. What defeats it is architecture: keys that never exist in the browser in the first place.

Why the store signals do not protect you here

Both major stores run review processes, and both catch a great deal. Mozilla's Recommended Extensions program involves technical review by staff security experts and carries a badge, and Mozilla is candid that its review systems cannot guarantee extensions are 100% safe. That honesty is the right starting point, because the campaigns above were built specifically around the gap it names.

Reviews and install counts describe history, not current code. When a listing is converted by an update, every accumulated signal transfers to software that has nothing to do with what earned them. Mozilla's own suggested questions — is the extension made by a reputable developer, are the user ratings high, are the permission requests consistent with the features — remain good questions, and the third is the strongest of the three, because it is the only one that interrogates the extension's behaviour rather than its reputation. A scores app requesting access to all sites would be exactly the mismatch that question is designed to surface.

The practical reading is not that store signals are worthless — they usefully filter obvious junk. It is that they are a floor rather than a ceiling, and that the most important question is not whether an extension was trustworthy when you installed it, but whether you would still accept its permissions today for what it actually does for you.

The ten-minute audit, and the boundary that actually holds

Open your browser's extensions page and read the list as though someone else installed it. Most people find between five and twenty entries and cannot say what several of them do. That gap is the whole problem, and closing it is quick.

Remove anything you do not actively use. This is not a judgement about whether it is malicious; unused extensions are pure exposure, because they carry permissions indefinitely and are updated by developers you stopped thinking about years ago. For each one that survives, ask Mozilla's consistency question directly: does what this thing does for me plausibly require reading and changing data on every site I visit? A note-taker, a theme, a scores widget, a coupon finder and a screenshot tool generally do not. Then check what each one is today — open its listing, see when it last updated, whether ownership changed, and whether recent reviews describe different behaviour from older ones. A cluster of recent complaints saying an add-on 'started doing something weird' is the signal the store's aggregate rating is too slow to show.

Then build the separation that makes the whole category smaller. Use a browser profile — or better, a browser — that exists only for wallets and exchanges, with no extensions installed except the wallet itself, obtained from the vendor's own published link. Do your reading, shopping and general browsing in the profile where your convenience extensions live. That single split means a compromised utility cannot see a session it was never present for, and it costs nothing but a second icon.

Now the boundary. Everything above reduces the odds; none of it survives a modified build of your own wallet, because there is no visible error to avoid. What survives is a hardware wallet, and the reason is structural rather than a matter of quality: the private key is generated on the device and never enters the browser, so an extension reading every page still finds nothing to steal. What it can still do is alter what a page displays, which is why the device's own screen matters — confirm the destination address and amount on the hardware screen, not on the page asking you to approve. That check is the last thing standing when everything else has been compromised, and it is the one people skip precisely because it looks redundant.

FAQ