Glassworm takedown and the supply chain risk you inherit

On May 26, 2026, CrowdStrike, Google, and the Shadowserver Foundation disrupted Glassworm, a Russia-linked botnet that targeted software developers through poisoned npm packages, Visual Studio Code extensions, and GitHub repositories. Any business that consumes open-source software inherits the risk. Organizations should check network logs for connections to 164.92.88.210 and review their software supply chain controls.

What is the Glassworm malware campaign?

Glassworm is a Russia-linked malware campaign, active since at least early 2025, that lived inside the tools software developers actually use every day. According to CrowdStrike, the operators systematically targeted developers because developer machines hold credentials to source code repositories, cloud platforms, CI/CD pipelines, and package registries — a uniquely high-value entry point into the rest of the company.

The campaign spread through three main channels. The first was trojanized Visual Studio Code (VS Code) extensions published to the OpenVSX marketplace and Microsoft's official Visual Studio Code Marketplace, disguised as common tools such as time trackers and code formatters. CrowdStrike notes the malicious extensions also targeted alternatives including Cursor, Positron, Windsurf, and VSCodium. The second channel was compromised npm and Python packages whose install scripts executed code silently during routine dependency installation. The third was more than 300 legitimate GitHub repositories that the operators poisoned by force-pushing malicious commits using stolen developer credentials.

The malware itself includes a Node.js remote access tool that CrowdStrike calls GlasswormRAT, browser credential stealers, cryptocurrency wallet phishing components targeting Ledger and Trezor users, and information-stealing modules. The operators evolved continuously over more than a year, rewriting the malware across JavaScript, Rust, and Zig and expanding to Windows, macOS, and Linux.

CrowdStrike attributes the activity to likely Russia-based cybercriminals on the basis of two consistent patterns: the malware checks the victim's locale and quietly exits on systems in the Commonwealth of Independent States (CIS), and Russian-language comments appear throughout the source code.

Why the Glassworm takedown matters to non-developers

Glassworm targeted developers, but the consequence falls on every business that consumes the software those developers build. A single compromised developer can poison code that ships into thousands of downstream customer environments. For mid-market and regulated businesses, the software supply chain is now an attack surface — one that traditional vendor questionnaires and antivirus tooling were never designed to cover.

CrowdStrike framed it directly: “The software supply chain remains one of the most consequential attack surfaces in modern computing.” Every SaaS product, every cloud-hosted application, and every CI/CD pipeline that pushes updates into your environment depends on developers who use the same package registries and extensions Glassworm poisoned.

The Verizon 2026 Data Breach Investigations Report flagged the same shift from a different angle: vulnerability exploitation has overtaken stolen credentials as the most common way attackers gain initial access. Supply chain malware sits in the overlap — it exploits the trust relationship between a developer and a package registry, then turns that trust into credential theft.

That is the gap most boards have not closed. A vendor risk program built around annual SOC 2 reports does not see what's happening inside a developer's IDE. A vCISO (virtual Chief Information Security Officer) leading the governance side of cybersecurity consulting needs to translate threat intelligence like the Glassworm campaign into a control set that fits the actual environment — not a checklist built for a different decade.

How did Glassworm get inside developer tools?

The operators used three intrusion paths in parallel. They published trojanized VS Code and OpenVSX extensions disguised as common utilities; they trojanized npm and Python packages whose install scripts executed code during dependency resolution; and they used stolen developer credentials to push malicious commits directly into more than 300 legitimate GitHub repositories. To evade code review, the malware used Unicode hiding techniques to embed payloads in characters that look invisible in most editors.

The infrastructure side is what makes Glassworm worth studying. CrowdStrike describes four command-and-control channels designed to resist takedown. The first is the Solana blockchain — C2 server addresses were encoded into the memo fields of public blockchain transactions, creating an immutable dead drop that cannot be removed once published. According to research from Step Security, the Solana network was queried every five seconds for new instructions. The second is the BitTorrent Distributed Hash Table (DHT), a global peer-to-peer network with no single point of failure. The third uses Google Calendar event titles to hide Base64-encoded C2 paths. The fourth is traditional C2 infrastructure on commercial VPS providers.

This design is why the takedown required CrowdStrike, Google, and the Shadowserver Foundation to strike all four channels simultaneously. Taking down one channel would have left the others operational and let the operators rebuild within hours. The coordinated action severed infected machines from operator control on May 26, 2026 at 14:00 UTC.

How to tell if your environment was touched by Glassworm

CrowdStrike has redirected all Glassworm-infected machines to beacon to a sinkhole IP address operated by the company. Organizations should review network logs and endpoint telemetry for outbound connections to that address. In CrowdStrike's words: “All Glassworm-infected machines now beacon to the benign CrowdStrike-operated IP address 164.92.88.210. Organizations should review network logs and endpoint telemetry for connections to this address. Any match indicates a Glassworm infection that requires immediate remediation.”

A match is not the end of the work — it is the beginning. The next questions are which packages and extensions the infected developer installed, which credentials lived on that machine, which repositories that developer could push to, and which downstream customers consumed code committed in the affected period. That sequence is the same scope question that drives any incident response services engagement: contain, identify what was accessed, and rebuild trust in what shipped after the compromise.

Detection alone is not enough. CrowdStrike makes the point explicitly: malicious packages are installed in seconds, and most detections happen after the harm is already done. Catching one machine matters; rebuilding the dependency graph and credential trust around it matters more.

What businesses should do this week

The reasonable next steps are concrete and limited — this is not a “boil the ocean” moment. Every business should treat the Glassworm takedown as a prompt to inventory the software supply chain, not just patch what is in front of them.

Start with the published indicator. Search EDR, SIEM, and firewall logs for any outbound connection from a workstation, build server, or developer environment to 164.92.88.210. Any hit is a confirmed infection that needs containment and credential rotation before anything else.

Audit installed extensions on developer IDEs. If your team uses Visual Studio Code, Cursor, Positron, Windsurf, or VSCodium, the publisher of every installed extension should be known, expected, and signed. Anything unrecognized comes out.

Rotate developer credentials with broad reach: GitHub personal access tokens and SSH keys, npm publish tokens, PyPI tokens, OpenVSX publisher credentials, cloud and CI/CD credentials stored on developer workstations, and any secrets in local environment files. Treat any developer machine active during the campaign window as potentially compromised until proven otherwise.

Tighten the build pipeline. Allowlist trusted package sources, require signature verification where supported, and route dependency updates through a review queue rather than a direct pull. The cost is days of friction. The alternative is finding out the hard way which of your customer-facing products inherited a poisoned dependency.

For ongoing governance, this is where vCISO services and fractional CISO services earn their keep — translating threat intelligence like the Glassworm campaign into a small, prioritized set of controls that fits the actual environment. Tie supply chain risk into the next risk assessment services engagement, not the next annual vendor questionnaire. Make sure someone owns the question “who has the keys to our software supply chain” before a board member asks it under duress.

Frequently asked questions

Is Glassworm still a threat after the takedown?

The takedown disconnected existing Glassworm infections from operator control, but it did not remove the malware from infected machines. Compromised systems still need to be cleaned, credentials rotated, and any code or packages published from those machines reviewed. CrowdStrike has also been clear that this is a disruption, not a permanent end — the operators are well-resourced and have rebuilt infrastructure before.

Does Glassworm affect companies that don't build software?

Yes. Most businesses are downstream of someone else's developers, whether through SaaS products, web applications, or third-party platforms. A poisoned package upstream becomes your problem when a vendor ships an update or discloses a breach. The Glassworm campaign deliberately targeted developers because their access cascades into thousands of downstream organizations.

What credentials should developers rotate after a suspected Glassworm exposure?

Anything tied to source code, package publishing, or cloud platforms. That includes GitHub personal access tokens and SSH keys, npm publish tokens, PyPI tokens, OpenVSX publisher credentials, cloud provider keys, CI/CD pipeline secrets, and any credentials stored locally on the affected workstation. Reset multi-factor authentication and review session activity for the same accounts.

Why is supply chain malware harder to detect than traditional attacks?

Because malicious code arrives through a trusted channel — a routine npm install, a VS Code extension update, a git pull — and runs as the developer, with the developer's permissions. Traditional antivirus does not flag legitimate dependency installation, and most code review processes do not catch payloads hidden in invisible Unicode characters. Detection has to come from earlier in the pipeline: allowlists, signed packages, and behavior monitoring on developer machines.

Was Glassworm only a developer problem?

No. CrowdStrike framed Glassworm as a supply-chain operation specifically because developers were the entry point, not the destination. The actual targets were the customer environments downstream of compromised developers — every business that consumes the affected packages, extensions, or repositories.

If you're not sure whether the Glassworm takedown applies to your environment — or whether your software supply chain has a gap that a similar campaign could exploit — a focused risk assessment is the fastest way to find out. Purple Shield Security works with mid-market and regulated businesses on supply chain risk, incident response, and the executive guidance that catches these gaps before they become disclosures. If you want a second set of eyes, that's a conversation worth having.

By Yonatan Hoorizadeh — CISSP, CISM, CRISC, AAISM

Published By: Purple Shield Security

Published: May 27, 2026

Last updated: May 27, 2026