GlassWorm shows how compromised IDEs extend AI coding risk

At a glance

What this is: GlassWorm is a self-propagating malware campaign that weaponises compromised developer accounts and extension marketplaces to spread into developer IDEs and AI coding assistants.

Why it matters: It matters because developer environments now sit inside the identity perimeter, so IAM, secrets governance, and software supply-chain controls all need to account for extension-level compromise.

👉 Read Knostic's analysis of GlassWorm in VS Code extensions

Context

IDE extension ecosystems are now part of the identity and access attack surface, because a trusted package can inherit the permissions, tokens, and workflow reach of the developer who installs it. In this case, the problem is not only malware distribution. It is the reuse of developer trust to move from one account to many systems through marketplace propagation.

For IAM and NHI programmes, the key issue is that developer workstations, extension registries, and AI coding assistants can become high-value access brokers. If a compromised extension can scan for credentials, tokens, and wallet material, then the boundary between endpoint security and identity governance disappears in practice.

Key questions

Q: How should security teams respond when a malicious IDE extension appears in a developer marketplace?

A: Contain the publisher account first, then remove or disable the extension, invalidate any tokens exposed to that environment, and review downstream package or cloud access for reuse. The key is to treat the marketplace account as an identity incident, not only a malware event. If the publisher can still update packages, the compromise is not over.

Q: Why do compromised developer extensions create more risk than ordinary endpoint malware?

A: Because they can inherit trust from the developer account, reach package registries, and expose secrets that are valid outside the workstation. That turns one infected endpoint into a publishing and credential problem. The risk is not limited to the machine, because the stolen identity material can open source control, cloud, and build systems.

Q: What do teams get wrong about securing AI coding assistants?

A: They often focus on model behaviour while ignoring the extension and registry layer that feeds the assistant. If the assistant shares the same trust path as the IDE, a compromised plugin can influence both human and AI-assisted workflows. Security teams need to govern the surrounding identity and update channels, not only the model.

Q: How can organisations reduce the blast radius of secrets stolen from developer tools?

A: Scope each secret to one function, reduce its lifetime, and remove broad publish or deploy permissions from developer-held tokens. The goal is to make any stolen credential unusable outside a narrow workflow. Shared tokens with package-publishing or cloud-admin reach create the widest downstream exposure.

Technical breakdown

How compromised extension marketplaces turn IDE trust into propagation

Open extension registries create a distribution layer that looks like normal software supply but behaves like an identity-dependent delivery path. When an attacker controls a developer account, the uploaded extension inherits marketplace trust, installation trust, and in many cases runtime trust inside IDEs such as VS Code and AI coding tools that consume the same registry. That makes the extension itself a propagation mechanism. The security problem is not limited to code review. It is the combination of account compromise, marketplace acceptance, and user-side execution that allows malware to move laterally through developer populations.

Practical implication: treat extension registries as identity-bearing infrastructure and apply approval, validation, and revocation controls to every publisher account.

Why credential harvesting from developer tools is especially damaging

GlassWorm is designed to search for reusable identity material, including developer credentials, npm tokens, and wallet data. That matters because developer environments often contain standing access to source control, package managers, cloud APIs, and automation pipelines. Once one of those secrets is exposed, the attacker does not need to stay inside the IDE. They can move into build systems, package publishing, or cloud resources using legitimate credentials. Invisible Unicode and payload updates delivered through blockchain transactions are delivery tricks, but the real risk is identity reuse across tools that were never meant to share the same blast radius.

Practical implication: reduce the value of harvested secrets by segmenting credentials by function, scope, and lifetime.

Why AI coding assistants widen the blast radius of an infected extension

AI coding assistants that rely on the same extension ecosystem inherit the same trust and update path as the IDE. That means a malicious extension can reach both human developers and the AI-assisted workflow they depend on, even if the assistant itself is not the malware target. The issue is governance convergence: one compromised plugin can influence code editing, token handling, and helper workflows at the same time. This is not a new class of autonomy problem, but it is a broader non-human identity problem because the tooling ecosystem now concentrates access, context, and execution in one place.

Practical implication: inventory which AI coding tools share extension trust with developer IDEs and separate them where possible.

Threat narrative

Attacker objective: The attacker wants durable access to developer identities and publishing channels so they can spread malware, steal reusable secrets, and extend compromise into build and cloud environments.

1. Entry occurs when attackers abuse compromised developer accounts to upload infected extensions into the OpenVSX ecosystem, giving the malware a trusted distribution path into IDEs and AI coding tools.
2. Escalation occurs when the extension scans for developer credentials, npm tokens, and wallet data that can be reused to take over package publishing or adjacent systems.
3. Impact occurs when malicious extensions remain live and continue spreading, allowing repeated credential theft, software supply-chain compromise, and persistence inside developer workflows.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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

NHI Mgmt Group analysis

Identity trust in developer ecosystems is now a supply-chain control problem, not just an endpoint problem. GlassWorm shows that extension registries can become identity distribution systems when they are tied to compromised publisher accounts. The malware does not need novel exploitation of the IDE itself if it can inherit trust through the account that publishes to the marketplace. Practitioners should treat publisher identity, package integrity, and installation trust as one governance surface.

Developer credentials create a larger blast radius than the workstation they sit on. The campaign’s value comes from harvested npm tokens, developer accounts, and wallet material that can be reused outside the original machine. That is a classic NHI problem because secrets outlive the device, and access can be reissued through package update paths and cloud automation. The practitioner conclusion is to govern developer-held secrets as production-grade identities, not convenience artifacts.

Open registries need lifecycle governance, not just malware scanning. The persistence of compromised extensions after warnings shows a failure of offboarding and revocation discipline at the marketplace layer. If a malicious publisher or package can remain available after compromise, then validation is not functioning as an identity control. Teams should assume that marketplace exposure is a standing risk unless removal, revocation, and publisher verification are enforced continuously.

AI coding assistants expand the trusted perimeter around non-human identity. When the same extension ecosystem feeds both human IDEs and AI-assisted development, the security model inherits the weakest trust assumption in both. That creates a concentrated control plane for code generation, package access, and secret handling. Practitioners should evaluate AI coding tooling as an access path, not only as a productivity feature.

Open extension ecosystems require identity-centric governance of software distribution. The named concept here is extension trust debt. It accumulates when organisations allow publishing, installation, and update authority to remain broader than the actual risk tolerance of the development environment. The practitioner implication is to reduce publishing trust before malware proves the gap for you.

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.
• 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.
• For practitioners dealing with exposed developer credentials, The 52 NHI breaches Report provides breach patterns that map directly to credential reuse and standing access failures.

What this signals

Extension trust debt: When publishing, installation, and update authority are broader than actual risk tolerance, the development stack accumulates hidden access debt that behaves like an identity problem. Teams should now review IDE and AI coding assistant channels as privileged distribution paths, not optional tooling.

The operational signal is simple: if a developer secret can survive long enough to be reused, the environment has already failed the containment test. Our research shows leaked secrets still take an average of 27 days to remediate, which means response speed is often slower than attacker reuse.

This should push programmes toward tighter registry allowlisting, publisher verification, and secret scoping across developer workflows. For broader pattern recognition, practitioners can compare this incident style with the root-cause analysis in the 52 NHI breaches Report.

For practitioners

• Revoke publisher trust for compromised extension accounts Quarantine and revoke any developer account that can publish to extension or package registries until ownership, signing, and recovery are verified. Track publisher identity separately from the code artifact so a clean package cannot be reintroduced through a compromised account.
• Scan developer endpoints for reusable secret material Search workstations and CI-connected developer environments for npm tokens, cloud API keys, and wallet material that could be reused after extension compromise. Prioritise secrets with publish, deploy, or billing reach because those create the fastest path from IDE compromise to broader impact.
• Limit extension installation to allowlisted sources Restrict IDE and AI coding assistant extensions to approved registries or internal repositories where package provenance can be checked. Require a removal path for any extension that changes publisher identity, update behaviour, or network destinations unexpectedly.
• Separate AI coding assistant trust from IDE trust Review whether AI coding tools inherit the same extension and update channels as developer IDEs. If they do, isolate the tools, narrow the extension set, and treat the shared registry as a privileged access path rather than a convenience layer.

Key takeaways

• GlassWorm turns IDE extensions into an identity distribution channel, which means developer account compromise can propagate through trusted software paths.
• The campaign is dangerous because it targets reusable secrets such as developer credentials, npm tokens, and wallet material, not just local endpoints.
• The control gap is lifecycle governance for publisher identities and extension trust, which must be treated as part of the software supply chain.

Key terms

• Extension Trust Debt: The accumulation of risk when an organisation allows extension publishing, approval, and update authority to remain broader than the security value of the tools involved. In practice, it creates hidden propagation paths where a compromised publisher identity can move malware through trusted developer workflows.
• Developer Identity Perimeter: The set of accounts, tokens, registries, and automation paths that give a developer environment access beyond the local workstation. For security teams, it includes package publishing rights, cloud credentials, and AI-assisted tooling that can reuse the same trust boundary.
• Registry-Borne Malware: Malware distributed through a trusted software registry rather than a conventional phishing or drive-by path. It matters because the registry’s legitimacy can mask malicious code, especially when compromised accounts are used to publish or update packages.

What's in the full article

Knostic's full article covers the operational detail this post intentionally leaves for the source:

• The specific OpenVSX propagation pattern and how compromised developer accounts were used to keep malicious extensions moving.
• The malware’s loader-hiding methods, including invisible Unicode and PUA characters, which matter for detection engineering.
• The extension listings that remained live after warnings, showing where marketplace validation failed.
• The practical detection workflow demonstrated by Kirin when an infected extension is installed.

👉 The full Knostic post covers propagation mechanics, marketplace persistence, and detection examples.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.