TL;DR: Attackers have turned developer IDEs, extensions, packages and MCP-style tooling into a supply-chain entry point, with one compromised laptop able to cascade into downstream code and credential compromise, according to Knostic. The defence now has to move to execution time inside the developer environment, where malicious code actually lands.
At a glance
What this is: Glassworm is a developer-targeting botnet that used trojanized IDE extensions, poisoned packages and compromised repositories to seed supply-chain compromise through engineering workstations.
Why it matters: It matters because developer endpoints now sit inside the trust boundary for code, credentials and pipeline access, so IAM, PAM and NHI controls must extend into the IDE and adjacent tooling.
Context
Developer workstations are no longer just endpoints for writing code. They now hold source repositories, package-registry tokens, SSH keys, cloud credentials and AI-assisted tooling access, which makes them part of the software supply chain rather than a side channel to it. In this article, the supply-chain problem is not only malicious code in production dependencies but malicious code executing on the developer machine before code ever reaches a build system.
Glassworm illustrates that weakness because the operator used the development environment itself as the entry point, including IDE extensions, package installation flows and poisoned repositories. That creates a governance gap for identity teams as well as security teams: the controls that govern service accounts, tokens and privileged developer access must now cover the workstation context where those identities are used.
Key questions
Q: What breaks when developers keep nonessential or untrusted IDE extensions installed?
A: The attack surface expands quickly, and security teams lose control over what code executes inside the development environment. Untrusted extensions can introduce remote code execution, file exfiltration, or malicious configuration changes. Even a single weak extension can undermine machine integrity, expose local secrets, and create a bridge into connected systems.
Q: Why do developer credentials create supply-chain risk beyond repository access?
A: Because those credentials often control release, signing, and marketplace distribution, not just source-code access. If an attacker steals them, they can republish trusted artifacts, inherit legitimate distribution paths, and reach downstream users without breaking perimeter defenses. The risk comes from identity reuse across the software lifecycle, not from source control alone.
Q: What are the signs that an IDE trust control is failing?
A: Unexpected shells, outbound network requests, or file changes immediately after opening a project are strong indicators that automatic execution is occurring. Another sign is finding .vscode/tasks.json entries with folder-open triggers in repositories that are not supposed to run anything on open.
Q: How should teams respond when a developer toolchain compromise is discovered?
A: Contain the workstation, revoke any exposed tokens, review repository and package publishing activity, and rebuild trust in the affected developer accounts before restoring normal access. Because the compromise can propagate through source control and package ecosystems, response must include identity containment, not just endpoint cleanup.
Technical breakdown
Why developer IDEs became a supply-chain attack surface
Modern IDEs are no longer passive editors. They execute extensions, install packages, call remote services and increasingly interact with MCP-style tooling and AI assistants that can request code, context and credentials. That combination makes the developer workstation a runtime trust boundary, not just a user device. When malicious code enters through an extension or package, it can run before traditional perimeter, CI or repository controls see it. This is why after-the-fact detection struggles here: execution happens in the same environment that holds the secrets and signing material.
Practical implication: Treat the IDE as a controlled execution surface and govern what can run there, not just what can reach the repository.
How trojanized extensions and packages weaponise trust
Trojanized extensions and poisoned packages abuse normal developer behaviour. A code formatter, time tracker or dependency update looks routine, so users approve it quickly and the platform often allows code to run with minimal friction. Postinstall hooks, setup scripts and extension activation events are especially dangerous because they create automatic execution paths without a separate approval step. In a supply-chain context, that means the malicious payload does not need persistence inside production systems first. It only needs one trusted installation path on one developer machine to begin harvesting tokens or pushing malicious updates downstream.
Practical implication: Inspect installation-time and activation-time execution paths as privileged code paths, because they are effectively a hidden trust escalation.
Why credential harvesting on developer endpoints is an identity problem
The most damaging part of campaigns like Glassworm is not the malware itself but the identities it reaches. Developer laptops often hold cloud credentials, package registry tokens, GitHub access and SSH keys, which are effectively non-human identities or high-value secret material in practice. Once stolen, those credentials let attackers act as the developer, move into repositories or publish malicious code that appears legitimate. That is an IAM and NHI issue as much as an endpoint issue, because the blast radius comes from standing access, weak segmentation between personal and work contexts, and poor visibility into where secrets are exposed in the development workflow.
Practical implication: Reduce standing developer secret exposure and separate high-risk credentials from the interactive environment where extensions and assistants run.
Threat narrative
Attacker objective: Steal developer credentials and use trusted development paths to turn one compromised workstation into downstream supply-chain compromise.
- Entry occurred through trojanized IDE extensions, compromised packages and poisoned repositories that executed inside developer workstations.
- Credential harvesting followed as the malware collected cloud tokens, SSH keys and registry credentials present on the same laptop.
- Escalation and lateral movement happened when stolen access was used to force-push malicious code and seed downstream supply-chain compromise.
- Impact was the spread of a developer-targeting botnet capable of credential theft, remote access and broader repository poisoning.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Developer IDE security is now a supply-chain control problem, not an endpoint hygiene problem. The article makes clear that the attack surface is the place where code, packages, extensions, MCP connections and credentials meet. That means the governance question has shifted from whether developers are patched to whether the execution environment itself can safely evaluate third-party code. Practitioners should treat IDE security as part of software supply-chain governance.
Glassworm exposes a standing-secret problem on engineering laptops. The campaign depended on credentials already being present where malicious code could reach them. That is the same failure pattern that drives many non-human identity incidents: access exists longer than the task that needs it, so compromise becomes reusable. For identity programmes, the lesson is to control secret exposure at the developer edge, not only in build and deployment systems.
Execution-time inspection is the named concept this incident sharpens. After-the-fact detection is too late when malicious extensions, packages and scripts can execute in seconds. The useful control point is the moment a dependency, extension or assistant tries to run. That shifts governance from searching for compromise to constraining what is allowed to execute in the first place, which is the right model for developer-side supply-chain defence.
Repository trust and workstation trust can no longer be managed separately. Glassworm shows how stolen workstation identities can be converted into repository integrity failures with very little friction. That makes developer access, token scope and device context part of the same governance problem. Practitioners should align endpoint controls, IAM controls and software supply-chain controls as one operating model.
The next wave of supply-chain compromise will likely arrive through developer productivity tooling. The article points to IDEs, extensions and AI-assisted coding workflows as the new place where malicious code can hide in normal work. That does not replace classic dependency risk, but it broadens it materially. Security teams should assume the adversary will keep moving toward the fastest trust path available.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Agent Identity Standards Tracker
What this signals
Execution-time control is the point that matters here: developer security fails when teams rely on detection after installation instead of policy at the moment an extension, package or assistant tries to run. That means the governance model has to move left into the IDE, where the first malicious instruction is executed.
Identity and supply-chain controls now overlap on developer endpoints. When cloud tokens, SSH keys and publishing credentials sit beside extensions and assistants, an access decision becomes a supply-chain decision. Security teams should treat developer secret exposure as part of the software delivery trust model, not as a separate endpoint problem.
Threat Modelling AI Agents is useful here because AI-assisted coding expands the number of tools that can request code, context and credentials inside the same workflow. Practitioners need to decide which assistants can operate on sensitive repositories and which cannot, before those tools become another trust shortcut.
For practitioners
- Inventory developer-side attack surface Map every IDE, extension store, package manager, MCP connection and AI coding assistant used across engineering endpoints. You cannot govern what you do not inventory, and most organisations still lack a complete list of this surface.
- Block execution-time package and extension abuse Move controls to the point where code is about to run inside the IDE, including extension activation, dependency install hooks and remote code fetches. That is where malicious payloads turn from suspicion into compromise.
- Reduce secrets on developer endpoints Minimise cloud credentials, registry tokens and SSH keys available in interactive developer sessions, and separate high-value secrets from everyday coding contexts wherever possible.
- Tie workstation telemetry to identity response Use endpoint and network detections to trigger immediate token revocation, repository access review and developer account containment when malicious extension or package behaviour is observed.
Key takeaways
- Glassworm shows that developer IDEs are part of the supply chain, because the workstation can be the first place malicious code executes and the first place credentials are stolen.
- The incident demonstrates that extensions, packages and AI-assisted developer tooling can turn one compromised laptop into repository poisoning and downstream compromise.
- Security teams need execution-time controls, reduced secret exposure and identity response that includes developer accounts, tokens and publishing access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while SLSA sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Glassworm harvested secrets from developer workstations and used them to spread downstream. |
| NHI-05 — Overprivileged NHI | The attack benefited from high-value credentials and publishing access already present on laptops. | |
| NHI-07 — Long-Lived Secrets | Standing tokens and keys on developer endpoints created the persistence the malware needed. | |
| Recommendation — Scan developer endpoints and coding tools for secret leakage and revoke any exposed credentials immediately. Reduce overprivileged developer credentials and separate publishing access from routine coding sessions. Rotate long-lived developer secrets and remove any credential that persists beyond the task that needs it. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The campaign stole credentials first, then used them to move into repositories and downstream systems. |
| Recommendation — Map the campaign to credential access and lateral movement, then hunt for token theft and repo abuse. | ||
| SLSA | Supply Chain Integrity | The article is fundamentally about how compromised developer tooling can undermine supply-chain trust. |
| Recommendation — Use build provenance and artifact integrity checks to reduce the chance that compromised developer tooling reaches customers. | ||
Key terms
- Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
- Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.
- Execution-time control: A policy or guardrail that blocks or restricts a tool while it is running, before it can read secrets, execute commands, or exfiltrate data. For developer environments, execution-time control is the difference between observing a malicious artifact and stopping it from doing harm.
- Standing Developer Secrets: Standing developer secrets are tokens, keys and credentials that remain available in an interactive development environment longer than the task that needs them. They create a large blast radius because malware, extensions or assistants can reuse them without needing to escalate privileges first.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM and secrets management in the context of modern identity risk. It helps practitioners connect identity controls to the broader security programme that developers and platforms now depend on.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org