Glassworm shows why developer IDE security is now a supply-chain issue

At a glance

What this is: CrowdStrike's analysis of Glassworm shows a developer-targeting botnet that abused IDE extensions, package installs, and poisoned repositories to reach engineering workstations and downstream supply chains.

Why it matters: For IAM and security teams, this matters because developer laptops now concentrate source code, cloud credentials, CI/CD secrets, and SSH keys, turning workstation compromise into identity and supply-chain compromise.

By the numbers:

• CrowdStrike disrupted Glassworm on May 26, 2026, after the botnet had been active since at least early 2025.
• More than 300 poisoned GitHub repositories were force-pushed with malicious code using credentials harvested from earlier infections.

👉 Read Knostic's analysis of Glassworm and developer-targeting botnet risk

Context

Developer environments have become a security control plane, not just a coding surface. When attackers compromise an engineer's IDE, package manager, or repository workflow, they can reach source code, cloud credentials, and signing or deployment secrets without needing to break production first.

This article is about that shift in attack surface. Glassworm is a supply-chain campaign with a clear identity angle because the compromised endpoint also holds high-value human and non-human credentials, and the trust boundary between developer access and workload access is collapsing.

The takedown details are useful because they show how modern attacker infrastructure is built for resilience across multiple channels. That resilience makes prevention at the execution point more important than post-compromise cleanup, which is now the typical starting position for this class of risk.

Key questions

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. If malicious extensions, postinstall hooks, or setup scripts execute during normal developer workflows, the attacker can steal credentials, alter repositories, and persist before review or detection catches up. That is why execution-time control matters more than post-event cleanup.

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. When an attacker compromises that endpoint, the impact is not limited to the laptop itself. The stolen identity material can be reused to modify code, access services, and push compromise downstream into customers and production pipelines.

Q: How should security teams govern IDE extensions and MCP servers?

A: Treat them as executable trust relationships, not convenience features. Require inventory, source approval, permission scoping, and monitoring for every extension and MCP connection that can reach code, files, or build systems. If a tool can execute, read, or delegate actions, it needs the same governance discipline as any other privileged access path.

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.

Technical breakdown

Trojanized IDE extensions as the first execution layer

Glassworm used malicious VS Code extensions published to OpenVSX and disguised as benign developer tools. In practice, extension install and activation are privileged moments because the IDE trusts code that can inspect files, environment variables, and network locations. The attacker does not need a browser exploit or kernel access when the workspace itself will execute extension code. The same pattern applies across Cursor, Windsurf, VSCodium, and related editor ecosystems, which broadens the blast radius beyond a single product family.

Practical implication: control extension provenance and block untrusted code paths at install and activation time.

Package install hooks and dependency-time execution

Compromised npm and Python packages are dangerous because postinstall hooks and setup scripts execute automatically during dependency resolution. That means the code runs before most traditional security tools or manual reviews can intervene, especially on a developer laptop where speed is valued over scrutiny. In this campaign, package installation became an execution vector rather than a simple distribution mechanism, which is why dependency hygiene alone is not enough when attacker code can execute as part of normal workflow.

Practical implication: inspect dependency-time behavior, not just package reputation, before allowing install scripts to run.

MCP servers and AI-assisted workflows extend the trust boundary

The article's mention of every IDE, extension, every MCP server, and every npm and PyPI package reflects a broader shift: AI-assisted development introduces new trust relationships between the editor, the model, the tool server, and external packages. MCP servers can connect an assistant to code, files, and services, which creates another place where malicious code or over-broad access can be abused. That matters because the attacker no longer needs only a token or a password if the workflow itself can invoke tools on their behalf.

Practical implication: inventory MCP connections and constrain tool permissions with the same discipline used for privileged access.

Threat narrative

Attacker objective: The objective was to turn developer workstations into durable supply-chain footholds that could steal secrets, propagate malicious code, and reach downstream customers.

1. Entry began with trojanized IDE extensions, compromised packages, and poisoned repositories that delivered attacker code into developer workflows.
2. Credential access followed when the botnet deployed an infostealer and credential harvester against cloud credentials, password-manager data, SSH keys, and CI/CD secrets on the workstation.
3. Escalation and impact occurred when stolen credentials were used to force-push malicious code into repositories and to keep the botnet resilient across multiple command-and-control channels.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Execution-time control is the new trust boundary for software delivery. The campaign shows why after-the-fact detection is structurally weak when malicious packages install in seconds and extension code activates immediately. That timing gap means control must move to the point where code runs, not just where it is distributed. In governance terms, this is a detection-response latency problem, and the practical conclusion is that prevention must sit inside the developer workflow.

Developer execution sprawl: the article exposes how many different execution surfaces now exist on a single engineering workstation, from IDE extensions to package hooks to MCP servers. That sprawl creates governance debt because each surface has its own trust model, update path, and permission scope. Security teams should treat the whole developer toolchain as one control domain and standardise how software is allowed to execute.

Compromised credentials remain the bridge from endpoint compromise to supply-chain compromise. Glassworm's downstream impact depended on harvested credentials being usable for repository writes and related actions. This is the same failure mode that appears in many NHI incidents: stolen secrets are not just data, they are delegated authority. The governance lesson is that secret exposure windows, rotation discipline, and scoped write access determine whether a workstation compromise becomes a production event.

IDE security will increasingly overlap with agentic AI governance. The article's inclusion of MCP servers points to a future where editor tooling, assistants, and tool servers form a shared runtime trust layer. That changes how security teams should think about software development risk, because AI-assisted coding inherits the same identity and privilege problems as classic NHI sprawl. The conclusion is to govern the assistant and its tools as a privileged execution environment, not as a productivity feature.

From our research:

• 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.
• From our research: 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.
• For teams hardening developer identity and secret governance, Ultimate Guide to NHIs , Key Challenges and Risks helps frame the visibility, sprawl, and over-privilege problems that let workstation compromise become supply-chain compromise.

What this signals

Developer security is now identity security by another name, because the endpoint often holds the credentials that make the pipeline usable. The practical signal for programme owners is that extension governance, package trust, and secret exposure monitoring need to sit alongside access reviews and PAM controls, not outside them.

Execution-time trust gap: the governance problem here is not just bad software, but the delay between a malicious package being introduced and a control deciding it is unsafe. That delay is where compromise scales. Teams should anchor their programme to controls that inspect code at install or activation time and align that with the guidance in the NIST SP 800-53 Rev 5 Security and Privacy Controls.

The rise of MCP-connected assistants means developer toolchains are starting to inherit the same privileged access patterns that identity teams already manage in service accounts and automation. That makes the MITRE ATLAS adversarial AI threat matrix and NHI governance relevant together, because the attack surface now spans both agentic tooling and classic secret abuse.

For practitioners

• Inventory every developer execution surface Build a live list of IDE extensions, package managers, MCP servers, and assistant-connected tools across engineering endpoints. If you cannot see what can execute code, you cannot govern the trust boundary where Glassworm-class attacks land.
• 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. Use a control that evaluates code at execution time, not after it has already modified the workstation or repository.
• 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. Pair this with rapid revocation so harvested secrets cannot be reused after endpoint compromise.
• Use the takedown window to hunt and remediate Check telemetry for the Glassworm beacon address 164.92.88[.]210, review CrowdStrike's YARA rules for the RAT and downloader stages, and isolate any machine that matched. The goal is to remove persistence before the next payload cycle begins.
• Treat MCP access like privileged access Review which assistants and MCP servers can reach source repositories, files, or build systems, then limit those permissions to the minimum required for the task. Apply the same approval, logging, and offboarding discipline you would use for high-risk human or service accounts.

Key takeaways

• Glassworm shows that developer endpoints are supply-chain assets, because the secrets on the workstation can be as valuable as the code in the repository.
• The campaign relied on execution-time abuse across IDE extensions, package installs, and repository workflows, which means late detection is already behind the attacker.
• Security teams should govern developer tools, MCP connections, and secret material as one identity-bearing control domain, not as separate technical problems.

Key terms

• Developer Execution Surface: The collection of tools on a developer workstation that can run code, load extensions, or invoke scripts. It includes IDEs, package managers, assistant integrations, and connected servers. This surface matters because compromise here can turn routine development activity into initial access or supply-chain abuse.
• MCP Server: A Model Context Protocol server exposes tools, data, or actions to an AI assistant through a standard interface. In security terms, it is a trusted bridge between the model and enterprise systems, so permission scope, logging, and source trust become part of identity and access governance.
• Install-Time Execution: Code that runs as part of software installation or activation, such as postinstall hooks or extension startup logic. Attackers target this moment because the code executes before many users notice it and before some controls can inspect the payload. That makes it a high-risk point in developer workflows.
• Secret Exposure Window: The period during which a credential, token, or key is live and usable after it has been exposed or stolen. Shortening that window reduces the chance that attackers can reuse the secret for repository writes, cloud access, or lateral movement. This is a core NHI governance concern.

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.

👉 Knostic's full post covers the takedown details, infection scope, and defender actions for developer environments.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern enterprise access. It gives security and identity practitioners a common operating model for reducing credential abuse across human and non-human workflows.