GlassWorm botnet takedown: how to check if your extensions are still infected

For months, researchers described GlassWorm as basically unkillable. Its command-and-control ran partly on the Solana blockchain — you can't send a takedown notice to an immutable ledger. Then, on May 26, 2026, a coordinated operation killed it anyway. And here's the part nobody wants to hear: the GlassWorm botnet takedown does not clean the malware off the machines it already infected.

If you installed a VS Code or Open VSX extension in the last several months — or you share a network with developers who did — the botnet going dark changes less for you than the headlines suggest. Let me walk you through what actually happened, why it still matters for anyone with a crypto wallet extension in their browser, and what to check today.

What just happened: the GlassWorm botnet takedown

According to The Register and BleepingComputer, CrowdStrike, Google, and The Shadowserver Foundation jointly disrupted GlassWorm on May 26, 2026, ending a developer-targeting supply-chain campaign that had been running since October 2025.

The reason it took a coordinated operation is the interesting bit. In its own writeup of the takedown, CrowdStrike describes four parallel C2 channels the malware could fall back on: Solana blockchain memo fields, Google Calendar event titles carrying Base64-encoded server paths, a BitTorrent distributed hash table, and plain old VPS servers. Knock out one channel and the botnet just switches to another. To actually break it, all four had to go down at the same moment.

They pulled it off. Infected machines now beacon to a CrowdStrike-operated sinkhole instead of the attackers' infrastructure, which means the operators can no longer push new commands or new payloads. That's a genuine win, and it's rare to see a botnet whose primary infection vector was browser and IDE extensions get dismantled this cleanly.

Why it was so hard to kill

Most malware takedowns work because the infrastructure has a single point of failure — a domain, a hosting provider, a registrar you can lean on. GlassWorm deliberately removed that weak point, and the design is worth understanding because copycats will reuse it.

The Solana channel is the clever core. Instead of hardcoding a server address that defenders can seize, the malware read the memo field of transactions from a wallet the operators controlled, decoded a Base64 pointer, and fetched its next instruction from there. You can block a domain. You cannot un-write a blockchain transaction.

The Google Calendar channel is the same idea wearing a friendlier face: event titles acting as dead drops, hosted on a service almost no corporate firewall blocks. The BitTorrent DHT gave it a peer-to-peer fallback with no central node at all.

That's why partial disruption was useless. Take down the VPS servers and it falls back to Solana; kill the Solana lookups and it reads Google Calendar. The only move that worked was hitting all four at once — which is exactly why this needed CrowdStrike, Google, and Shadowserver acting together rather than any one of them acting alone.

The malware the takedown left behind

Here's why I'm not telling you to relax. A sinkhole severs the conversation between the malware and its operators. It does not reach into your machine and remove the extension that started the whole thing.

GlassWorm was, at its core, a self-propagating worm hiding inside developer extensions. Rescana's analysis and reporting from The Hacker News — corroborated by BleepingComputer, which counted more than 400 poisoned code repositories across GitHub, npm, VS Code, and Open VSX — describe extensions that impersonated trusted developer tools. The malicious code was hidden using invisible Unicode characters, so it literally vanished from view during a normal code review.

That invisibility is the whole trick. A maintainer or a security reviewer could stare at the source and see nothing wrong, because the payload was written in characters editors don't render. I broke down how that dropper stage works — the Zig binary, the Solana lookups, the silent install into every IDE on the machine — in my earlier piece on the GlassWorm IDE supply-chain attack. This article is the sequel: the campaign is disrupted, but the installed payloads are still sitting where they landed.

And the campaign was not small. The worm spread across Open VSX and VS Code from October 2025 onward, and researchers tracked a March 2026 wave that poisoned hundreds of components in a single push.

Once it landed on a machine, it didn't just sit there — reporting describes it deploying SOCKS proxy servers to turn infected developer boxes into criminal relay infrastructure, and installing hidden VNC servers for full remote access. So a "checked and looks fine" machine from three months ago is not automatically a clean machine today.

Why this reaches your browser, not just your IDE

You might be thinking this is a developer problem. It partly is. But GlassWorm didn't stop at stealing GitHub tokens and npm credentials — it reached straight into the browser.

Researchers reported that the malware targeted dozens of cryptocurrency wallet extensions — roughly 49 by one count — harvesting keys and credentials from browser storage in addition to developer secrets. The Chrome infostealer stage is what turns "a bad VS Code extension" into "my wallet got drained." If you keep a browser-based wallet like MetaMask, Phantom, or Trust Wallet on the same machine where a poisoned extension ran, that wallet was in scope.

This is the same brutal lesson from the wider infostealer wave I covered in the crypto wallet extensions security review: browser extension storage has become a primary target, and host-level malware doesn't care how careful you were about which wallet you chose. The extension can be perfectly legitimate. The problem is the malware running next to it.

And you don't have to be the one who installed the bad extension. If a teammate's machine got compromised and they had access to shared repos, cloud credentials, or CI/CD pipelines, the blast radius includes everyone downstream. That's the definition of a supply-chain attack.

How to check your extensions for malware now

The takedown bought you time, not safety. Here's what I'd actually do this week.

1. Audit your IDE extensions — and your teammates'. Open VS Code (or whatever Open VSX-compatible editor you use) and review every installed extension. Remove anything you don't recognize, anything installed in the last several months that you can't account for, and any tool that "updated itself" oddly. Because GlassWorm silently installed itself into every compatible editor on the machine, checking one editor isn't enough — check all of them.

2. Treat a compromised machine as compromised, sinkhole or not. If you find a suspicious extension, assume anything that machine had access to is exposed. Rotate the credentials that matter: GitHub and npm tokens, cloud provider keys, SSH keys, and any API keys stored locally. The sinkhole stops new commands; it does not un-leak the secrets already exfiltrated.

3. Move real crypto value off browser wallets. If you're holding meaningful amounts in a browser extension wallet, and there's any chance host malware touched that machine, move funds to a hardware wallet and treat the old seed phrase as burned. This isn't about MetaMask or Phantom being insecure — it's about the risk profile of any secret stored on a machine that may have run an infostealer.

4. Learn the ClickFix pattern, because the takedown won't stop it. GlassWorm and its cousins lean heavily on ClickFix social engineering — a page that instructs you to paste a command into a terminal or press a keyboard shortcut to "fix" or "verify" something. Any unexpected prompt asking you to run a script is a red flag. The infrastructure got dismantled; the playbook that infects the next victim did not.

5. Review your browser extensions against real security data. Beyond the wallet question, this is a good moment to look hard at everything you've installed. Which extensions read data on every site? Which ones request permissions that don't match what they do?

That's exactly the kind of check I built Extenshi for. And it's not a one-off: campaigns keep recycling the same distribution tricks, from the zero-permission extensions that acted as malware droppers to the ShadyPanda cluster with 43M installs.

How Extenshi helps

A botnet takedown is a headline. Your actual attack surface is the pile of extensions you've quietly accumulated across Chrome, Firefox, and Edge — and most people have no idea what those extensions can touch.

Extenshi scans that pile against store metadata and security signals so you can see, at a glance, which extensions request risky permissions, which have thin or suspicious publishers, and which sit on the same threat-report lists that campaigns like GlassWorm exploit. You can't manually track four C2 channels or invisible Unicode payloads. You can keep a clear inventory of what you've installed and what it's allowed to do — and that inventory is where post-incident cleanup actually starts.

Check your extensions → Scan your browser extensions with Extenshi or browse the catalog to see how the extensions you already run score before the next campaign shows up.

FAQ: malicious browser extensions after a takedown

What can a malicious browser extension actually do? Whatever its permissions allow, and most people grant far more than they realise. In GlassWorm's case that meant reading browser storage — which is where crypto wallet extensions keep their keys. A <all_urls> host permission lets an extension read and rewrite every page you open, including your bank, your email, and your session cookies. The damage ceiling isn't set by the extension's category; it's set by its permission list.

How are malicious browser extensions spread? Three routes dominate. Poisoned updates to an extension you already trust (the supply-chain path GlassWorm used). Lookalike listings that copy a popular extension's name and icon. And sideloading, where malware on the machine installs the extension for you without a store visit ever happening — the pattern behind the Snowbelt sideloaded-extension attacks on enterprises.

How do I check for malicious browser extensions on my own machine? Open chrome://extensions/, switch on developer mode, and write down every extension ID you see. Anything you don't remember installing goes first. Then check what's left against permission and publisher data instead of star ratings — a five-star extension with 200k users can still have been sold to a new owner last month.

Does the takedown mean I'm safe now? No. A sinkhole cuts the malware's link to its operators. It doesn't uninstall the extension, rotate the credentials that already leaked, or give you back the crypto that already moved.

Sources

• CrowdStrike, Google shatter GlassWorm botnet — The Register
• GlassWorm botnet disrupted after resilient C2 infrastructure takedown — BleepingComputer
• Inside CrowdStrike's takedown of a developer-targeting botnet — CrowdStrike
• GlassWorm malware exploits VS Code and Open VSX extensions — Rescana
• GlassWorm supply-chain attack abuses 72 Open VSX extensions — The Hacker News
• GlassWorm malware hits 400+ code repos on GitHub, npm, VS Code, Open VSX — BleepingComputer

---

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].