When the store is the threat — 108 malicious Chrome extensions, one C2, 20,000 installs
A single operator pushed 108 malicious extensions onto the Chrome Web Store under five fake publishers, collected around 20,000 installs, and routed the lot to one command-and-control server. The review model didn't catch it. Here is why a security-first browser has to take a harder position.
A browser extension is a program you install that can read every page you visit, read every token your browser holds, and do things in your name. The Chrome Web Store promises to vet those programs. In April 2026, one operator published 108 of them, harvested roughly 20,000 installs, and routed all of it through a single server. The store did not notice.
On April 14, the application-security firm Socket
disclosed
a coordinated malicious-extension campaign in the Chrome Web Store.
Researcher Kush Pandya found 108 extensions published under five fake
publisher identities — Yana Project, GameGen, SideGames, Rodeo Games,
and InterAlt — all pointing at one shared command-and-control (C2)
server at 144.126.135[.]238. Between them, the extensions had been
installed roughly 20,000 times. The Hacker News
corroborated the numbers the same day.
The extensions were not a broken-URL nuisance or a bit of ad fraud tacked onto real software. They were a toolkit:
- 54 extensions stole the signed-in user's Google identity by scraping the OAuth2 Bearer token — the short-lived string Chrome sends to identify you to Google services — the moment the tab loaded.
- 45 extensions carried what Socket describes as a universal backdoor: they opened arbitrary URLs on browser startup, based on commands fetched from the C2. That is a primitive for click fraud, drive-by downloads, or quiet navigation to an exploit page.
- Others injected attacker-controlled HTML into real sites, stripped HTTP security headers so injected content could actually run, hijacked Telegram Web sessions on a 15-second clock, proxied translation requests through the attacker, or wrapped YouTube and TikTok pages in gambling overlays.
The code carried Russian-language comments in the authentication and session-theft paths. The researcher notes the operator's identity is unknown; the infrastructure was hosted on a Contabo VPS with subdomains split by function (identity collection, command execution, monetization, session hijacking).
At the time the story broke, none of the 108 extensions had been removed from the Web Store.
What an extension actually is, and why this is not just another malware story.
Most people install browser extensions the way they install fonts: they find one that seems useful, click the blue button, and forget about it. The "permissions" dialogue that sometimes appears is a legacy of earlier and clearer days. In Chrome's current extension model, a very large fraction of real extensions ask for something close to the following, and the user has no meaningful way to say no partially:
Extensions sit above the same-origin policy that keeps tabs isolated from each other. That is the entire point of them: an ad blocker would not work if it could not read the ad on every site, and a password manager would not work if it could not watch every login form. The browser, quite reasonably, does not distinguish at runtime between "ad blocker reading the page to hide a banner" and "malicious extension reading the page to steal your session token." They are the same capability, granted for different reasons.
What Socket's 108 extensions did, then, is not some clever bypass of Chrome's security. It is the normal, documented behaviour of the extension platform, pointed at an operator's server instead of at the user's benefit.
Five fake publishers, one server, 20,000 installs.
The campaign's shape is what matters. One actor, a handful of sock-puppet publisher accounts, a catalogue built to look superficially diverse — slot and keno games, YouTube and TikTok "enhancers," Telegram-sidebar utilities, translation tools, cursor decorations — all routing back to the same IP. Taken individually, any one of these extensions looks like low-grade junkware. Taken together, they are an industrialised harvest.
Five publishers are not the outer limit of the pattern; they are the surface of it. In parallel with the Socket disclosure, the firm LayerX Security published an expansion of what they call the GhostPoster campaign, tracing related malicious extensions across Chrome, Firefox, and Edge, with cumulative downloads in the hundreds of thousands and origins going back to 2020. The takeaway is not that a specific gang got caught. The takeaway is that the extension-store model — user trusts store, store reviews at submission, store mostly trusts publisher identity going forward — has been failing quietly, at scale, for years.
Bromure's answer: don't allow extensions at all.
Bromure is a security-first browser. Each tab runs inside a disposable Linux VM (virtual machine — its own separate computer, wiped when the window closes) on your Mac. Inside that VM, we install Chromium with a stripped-down policy. Two lines in that policy matter for this story:
chrome://extensionsis blocked.chromewebstore.google.comis blocked.
There is no "warn the user and let them proceed" flow, no "advanced
settings to allow it anyway," no developer-mode exception that a
phishing page can walk you through. The user cannot reach the Web
Store from a Bromure session, and even if they had the .crx file
already on disk, the extensions page is not reachable to load it. The
attack surface that the GhostPoster campaign relied on does not exist
here.
This is, to be clear, a deliberate design choice, not an oversight. Bromure's position is that any browser that permits user-installable extensions is structurally vulnerable to campaigns like this one. Not "vulnerable if the store gets lax." Structurally vulnerable. The store review is the only thing standing between the user and a program with page-wide access, and "the store review" has now publicly failed at industrial scale, in a named campaign, with a named operator infrastructure, with 20,000 installs. Asking the user to make a better judgement than Google's reviewer team is not a security model.
The hard version of this position — Bromure's version — is to remove the capability. No user-installable extensions. No advanced toggle. No "unlisted extensions, loaded from a .crx, for power users." The attacker cannot exploit a capability the browser does not offer.
What this costs, and why the tradeoff is honest.
Being honest about this: it is a real tradeoff, and it is worth naming clearly.
No uBlock Origin
Bromure ships its own content-filtering layer at the VM and network level, but if you were using uBlock Origin specifically, you will not have it here. You can read our separate post on how Bromure handles ads; the short version is that ad blocking moves out of the browser and into the infrastructure underneath it.
No 1Password, no Bitwarden, no LastPass extension
Your password manager's browser extension does not install in Bromure. Password managers work fine as native apps on your Mac, and most of them will happily copy-paste or auto-type into the browser from outside. It is a change in workflow, not a loss of the tool.
No Grammarly, no React DevTools, no Web3 wallet
The category of "extensions that add a feature to your browsing" and the category of "extensions that hold keys to your digital life" both go away. For most users, the first category is a small loss. For developers or crypto users, it is larger. If that loss is a dealbreaker, Bromure is not your primary browser — and that is a fair answer.
What you get in exchange
108 malicious extensions cannot land on your Mac, because there is no channel to install them. Five fake publishers cannot fool a review process that does not exist, because you are not invited to trust reviewers in the first place. The attack surface in this story — the central one — is closed.
One nuance worth stating plainly. Bromure does load a small number of first-party extensions inside the VM — a credential bridge to talk to your Mac's password manager, a WebRTC-blocker for the IP-leak cases we've written about before, and a couple of other instrumentation helpers. These are part of the browser's own architecture, baked into the disk image, not something a running session can add to or replace. They are not a loophole to install user extensions through; they are the browser being the browser. Calling them "extensions" is honest naming for the mechanism, not a secret store.
The review model is what's broken.
It is tempting to read the 108-extension story as a story about Google specifically. It is not. Mozilla's add-on store and Microsoft's Edge store have, according to LayerX's wider tracking, hosted related campaigns for years — in some cases originating on Edge and only later expanding to Chrome. The common factor is not a specific reviewer team. It is the model: submit, get approved, publish, and then push auto-updates to installed users with minimal ongoing oversight. Any program that will be run on millions of machines under that model will, eventually, attract people willing to industrialise the gap.
This is a smaller browser because of that decision. That is the point. A security-first browser that still says yes to every extension in the Web Store is not a security-first browser; it is a regular browser with a different logo. When the store is the threat, the only honest answer is to not take extensions from the store. Your Mac will, in our view, end up safer.
If you want what Bromure does, install it and try it as your default for the risky half of your browsing — the clicked links from group chats, the search results you are not quite sure about, the work email attachments that always seem to open "a page." If the GhostPoster operator is still out there, and the next 108 extensions land tomorrow, a Bromure session will not find out.