TL;DR: CrowdStrike says Glassworm has targeted software developers since at least early 2025, using trojanized VS Code extensions, compromised npm and Python packages, and poisoned GitHub repositories to seed a botnet that can steal credentials and push supply-chain compromise downstream. The takedown buys time, but it also shows that developer workstations have become a primary supply-chain attack surface, not just production build pipelines.
NHIMG editorial — based on content published by Knostic covering CrowdStrike's Glassworm takedown: Disrupting Glassworm and the developer-targeting botnet threat
Questions worth separating out
Q: What breaks when malicious code can run inside a developer IDE or package install?
A: Traditional endpoint and supply-chain controls lose time to the same mechanism they are trying to inspect.
Q: Why do developer workstations increase supply-chain risk so quickly?
A: Developer workstations concentrate source code, cloud credentials, CI/CD secrets, SSH keys, and repository permissions in one place.
Q: How should security teams govern IDE extensions and MCP servers?
A: Treat them as executable trust relationships, not convenience features.
Practitioner guidance
- Inventory every developer execution surface Build a live list of IDE extensions, package managers, MCP servers, and assistant-connected tools across engineering endpoints.
- Block install-time code execution by policy Restrict extension activation, postinstall hooks, and setup scripts unless the source is approved and the behavior is explicitly expected.
- Harden developer identity material on endpoints Separate cloud credentials, SSH keys, and password-manager access from everyday editor processes, and enforce scoped access for repository write operations.
What's in the full article
Knostic's full analysis covers the operational detail this post intentionally leaves for the source:
- The full attacker tradecraft behind Glassworm's extension, package, and repository infection paths.
- The specific command-and-control infrastructure CrowdStrike disrupted across blockchain, peer-to-peer, and web services.
- The published YARA rules and hunting indicators for the RAT and downloader stages.
- The remediation actions for engineering fleets that matched the 164.92.88[.]210 beacon.
👉 Read Knostic's analysis of Glassworm and developer-targeting botnet risk →
Glassworm and developer IDE risk: what security teams need to do now?
Explore further
Developer workstations are now identity-bearing supply-chain nodes. Glassworm is not just endpoint malware, because it targets the place where human identity, machine identity, and build identity intersect. The developer laptop holds cloud credentials, CI/CD tokens, SSH keys, and source code signing paths, so compromise there becomes both access theft and supply-chain insertion. For IAM teams, this is a reminder that developer endpoints must be governed as part of the identity estate, not treated as ordinary user devices.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when a compromised developer credential reaches the supply chain?
A: Accountability usually spans identity, endpoint, and software delivery owners because the failure crosses all three domains. The control gap is often weak lifecycle management for secrets and overly broad repository rights. Frameworks such as NIST CSF, NIST SP 800-53, and OWASP NHI are relevant when compromise turns stolen access into downstream code execution.
👉 Read our full editorial: Glassworm shows why developer IDE security is now a supply-chain issue