Eighteen Chrome extensions and one Edge extension, published over a six-month stretch, all sharing the same code and the same tradecraft, all quietly built to steal crypto wallet secrets and drain funds. That’s what Socket researcher Karlo Zanki found when he started pulling threads on what looked, on the surface, like a handful of unrelated productivity and utility add-ons. It wasn’t a handful. It was a pipeline. And it sailed through official extension review processes for months without anyone flagging it, which is the part that should actually worry anyone running a cybersecurity program built around network perimeter defenses.

This is the uncomfortable truth about browser extensions in 2026: they are software supply chain risk wearing a costume of convenience, and most enterprise security programs still treat them as an afterthought. Firewalls don’t inspect them. Endpoint detection often doesn’t track them. And the store review process that’s supposed to catch this stuff keeps getting walked around by the same handful of tricks, campaign after campaign.

Incident Summary: 19 Extensions, One Shared Codebase, Six Months Undetected

The extensions Zanki tracked weren’t obviously malicious on install. They presented as legitimate tools, the kind of thing you’d add to your browser without a second thought, then quietly requested the broad permissions extensions typically get away with asking for: reading and modifying data on every website you visit. That permission is the entire attack. Once granted, the extension can watch for wallet activity, intercept seed phrases, and reroute transactions, all inside a browser session the user trusts completely.

What makes this campaign notable isn’t the individual technique, wallet-draining extensions aren’t new, it’s the scale and the patience. Nineteen separate listings, built from shared source, published gradually over six months rather than dumped all at once. That cadence looks deliberate: spread the submissions out, avoid pattern-matching detection that flags a burst of similar-looking listings, let each one accumulate some install base and positive reviews before the next batch goes up. It’s the same patience you’d expect from a well-run fraud operation, applied to a browser extension store instead of a bank.

Root Cause: The Store’s Trust Model, Not the Code Review

Here’s the part that deserves blunt language: this keeps happening because the trust model for extension marketplaces is fundamentally mismatched to the threat. Store review processes are built to catch obviously malicious code at submission time. They are not built to catch a benign-looking extension that gets a “feature update” three months later, and they are not built to catch a coordinated campaign that deliberately looks like nineteen unrelated developers rather than one operator.

This is not a knock on any single vendor’s review team. It’s a structural problem. Extensions get code-signed and distributed the same way any other software supply chain component does, but almost nobody in enterprise IT treats them that way. You’ve got asset inventories for servers, for SaaS accounts, for certificates. Very few organizations have one for browser extensions, despite the fact that a wallet-draining extension and a session-hijacking extension use the exact same permission model to do very different kinds of damage. The absence of that inventory is itself the vulnerability, the same lesson showing up right now in a completely different context: organizations scrambling to build cryptographic inventories ahead of the post-quantum transition are learning that you cannot secure, patch, or govern an asset class you’ve never bothered to catalog.

Impact Analysis: Why Your Firewall Never Saw This Traffic

Traditional threat detection is built around network signals: unusual outbound connections, command-and-control beaconing, brute-force login attempts against exposed services. A malicious extension doesn’t need any of that. It operates inside a process the operating system and the network stack already trust, using a network connection the browser itself initiated. To a firewall, it’s indistinguishable from the user checking their portfolio balance on a legitimate site.

That’s the core failure mode worth sitting with. Defense in depth usually gets described in terms of layered network controls: perimeter firewall, segmented internal networks, endpoint protection, log-based threat detection catching the brute-force scans and credential-stuffing noise that hits every exposed service eventually. All of that is necessary. None of it touches what happens inside a browser tab once a user has granted an extension broad page access. The client side of the security stack, the actual software running on actual endpoints that isn’t a traditional executable, is where a lot of the real exposure now lives, and it’s the layer most cyber security programs invest in least.

Remediation: Bringing Extensions Into the Cybersecurity Perimeter

Fixing this doesn’t require exotic tooling. It requires treating browser extensions as the software supply chain risk they actually are, with the same rigor you’d apply to a third-party package pulled into a production build. A few concrete steps, in order of how fast you can act:

• Enforce an extension allowlist through browser management policies (Chrome Enterprise, Edge for Business, or equivalent) instead of leaving install decisions to individual users.
• Audit every currently installed extension across managed devices this week, not next quarter, and cross-reference against known-malicious listings as they’re disclosed.
• Restrict extension installs to a single approved store and block sideloading entirely on managed endpoints.
• Monitor for permission escalation on updates. An extension that silently adds “read and change all your data on websites you visit” after an update is a signal, not routine housekeeping.
• Fold browser extension telemetry into your existing incident response runbooks, so a compromised wallet or session isn’t treated as an isolated user problem but as a potential indicator of a broader campaign.

None of that requires new budget line items. It requires deciding that extensions belong in the same governance conversation as endpoint software and third-party dependencies, which for most organizations they currently don’t. Security hardening that stops at the network edge leaves this entire surface uncovered, and attackers have clearly noticed.

Sources

• 19 Chrome and Edge Extensions Found With Wallet-Stealing and Crypto-Draining Code