GlassWorm shows how compromised IDEs extend AI coding risk

At a glance

What this is: Knostic’s analysis of GlassWorm describes a self-propagating malware campaign using compromised VS Code extensions and OpenVSX to spread into developer environments and AI coding tools.

Why it matters: It matters because IDEs and AI-assisted development environments now function as privileged entry points, so IAM, secrets, and supply-chain controls must extend into the developer workflow.

Context

GlassWorm is a malware campaign that turns the IDE into a delivery channel by abusing trusted extension ecosystems. The article frames VS Code extensions, OpenVSX, and AI coding assistants as part of the same developer attack surface rather than separate tools.

For identity and access teams, the important issue is not just malicious code in a marketplace. It is the trust chain behind developer accounts, extension publishing rights, and the credentials that can be harvested from the workstation once the extension is installed.

Key questions

Q: What fails when a compromised IDE extension is allowed into a developer environment?

A: A compromised extension can turn a trusted IDE into a distribution and harvesting point. The failure is not only malware execution. It is the breakdown of publisher trust, extension provenance, and the assumption that developer tools are low-risk compared with production systems.

Q: Why do malicious IDE extensions create a supply chain risk for development teams?

A: Because the IDE sits between developers, source code, and build systems. If an extension can access tokens or modify project files, it can become a distribution point for credential theft or code tampering. That risk is amplified when developers trust third-party plugins more than they inspect the permissions they grant.

Q: What are the warning signs that an IDE extension is abusing trust?

A: Look for extensions that auto-activate, request broad OAuth scopes, proxy traffic through unusual domains, or run hidden background processes. Any extension that mixes login automation, environment-variable reads, and token handling should be treated as a high-risk trust boundary because it can silently exfiltrate secrets.

Q: How should security teams respond when developer tools and AI coding assistants share the same trust model?

A: Separate their permissions, review them as distinct trust domains, and limit what each can read or publish. If AI coding assistants inherit broad IDE access, the organisation is effectively expanding the blast radius of a single extension compromise.

Technical breakdown

How compromised extension publishing becomes a propagation path

GlassWorm abuses the trust model of open extension registries. When an attacker controls a developer account, they can upload or update a package that looks legitimate to the marketplace and then rely on automatic extension distribution into IDEs. That changes the registry from a distribution platform into a propagation path. The risk is amplified when users install extensions from shared marketplaces without verifying the publisher lineage or package integrity. Practical implication: treat extension publishing permissions and registry trust as part of the software supply chain, not as a low-risk developer convenience.

Practical implication: validate publisher identity and restrict who can publish or update extensions in your developer ecosystem.

Why IDE malware targets credentials, tokens, and wallets

The campaign scans for developer credentials, npm tokens, and crypto wallets because those artefacts unlock both code distribution and downstream compromise. In practice, a malicious extension can exfiltrate secrets from the local environment, then use them to publish new malicious packages or access adjacent services. That creates a bridge from endpoint infection to identity abuse across development tooling. Invisible Unicode and PUA characters make the loader harder to spot during manual review, while blockchain-based payload updates add another layer of operational concealment. Practical implication: assume the IDE can expose reusable secrets and monitor it accordingly.

Practical implication: extend secrets detection, token revocation, and endpoint telemetry into developer workstations and IDE plugin ecosystems.

What makes AI coding assistants part of the same identity risk

AI coding assistants that consume IDE extensions inherit the same marketplace trust problem, but with more privileged workflow access. Once an extension is installed, the assistant and the developer session may both become part of the attack path, because the malware is operating inside the tools used to write, review, and publish code. That is why this is not just endpoint malware. It is an identity and authorization problem inside the development toolchain. Practical implication: apply least privilege to AI coding integrations and separate extension trust from code-generation trust.

Practical implication: segment AI coding assistants from general IDE add-ons and review their permissions as distinct trust domains.

Threat narrative

Attacker objective: The attacker wants to convert trusted developer tooling into a repeatable distribution channel for credential theft and follow-on supply-chain compromise.

1. Entry occurs through compromised developer accounts used to upload infected VS Code extensions into OpenVSX.
2. Credential harvesting follows when the malware scans the workstation for developer credentials, npm tokens, and crypto wallets that can be reused.
3. Impact comes when stolen access is used to spread malicious extensions further and persist inside developer and package publishing workflows.

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.
• Amazon Q MCP config vulnerability 2026: A malicious .amazonq/mcp.json in a repository could make Amazon Q run commands with a developer's AWS credentials. Fixed before disclosure.

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 tooling is now a privileged supply-chain surface, not a peripheral workstation layer. GlassWorm shows that extension ecosystems can become propagation infrastructure when publishing trust is abused. That means the security boundary has moved from the endpoint alone to the registry, the publisher account, and the local secrets exposed inside the IDE. Practitioners should treat extension trust as a governed access path, not a software convenience.

Extension publishing identity is the control point the attack depends on. The article’s key failure mode is compromised developer accounts being able to push infected packages into a trusted marketplace. That is a governance problem, not just malware delivery. If publishing rights are weakly governed, one account compromise can become a multi-user propagation event across a development estate.

AI coding assistants inherit the same trust debt as the IDE they extend. The campaign matters because AI-assisted development expands the number of surfaces that can read code, tokens, and session state. In NHIMG terms, the issue is not whether the assistant is intelligent. It is whether the surrounding identity and permission model assumes the toolchain is benign. Security teams should re-evaluate where developer trust is being delegated implicitly.

Invisible payload techniques raise the cost of manual review, so governance has to move earlier in the workflow. Hiding loader code with Unicode and updating payloads through chained mechanisms shows that marketplace moderation alone is too late in the process. The practical conclusion is that registry validation, extension provenance, and workstation secret exposure need to be treated as one control plane, not separate reviews.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• 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: AI Coding Agents Security Guide

What this signals

Extension ecosystems now deserve the same governance discipline as package registries and source-control access. Once a trusted publishing account can push infected code into widely used IDEs, the security question becomes who is allowed to extend developer tooling and under what approval path. That is a lifecycle and provenance issue, not just malware detection.

Developer endpoints are now secret-bearing infrastructure. Malicious extensions target the same credentials that let engineers ship code, so the control plane has to include token scope, revocation speed, and workstation telemetry. According to the State of Secrets Sprawl 2026, Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025.

IDE and AI coding governance should move from allowlisting tools to governing trust pathways. The practical test is whether an organisation can prove which publishers, extensions, and assistants were authorised to influence code and credentials at the moment they were used.

For practitioners

• Audit extension publishing rights Identify every account that can publish or update IDE extensions in your environment and remove unnecessary rights. Require stronger approval for registry-bound publishing than for ordinary package access.
• Scan developer workstations for exposed secrets Monitor IDE hosts for developer credentials, npm tokens, wallet artefacts, and other reusable secrets that a malicious extension could harvest. Tie detection to rapid token revocation and account review.
• Separate AI coding tool trust from extension trust Review AI coding assistants, extensions, and marketplace access as distinct trust domains. Do not let broad IDE permissions silently expand what an assistant can read or influence.
• Validate extension provenance before rollout Use package provenance, publisher lineage, and controlled allowlists before extensions reach developer populations. Focus on preventing unsigned or unfamiliar extensions from becoming default tools.
• Add registry abuse to incident monitoring Watch for unusual extension updates, sudden publisher account changes, and malicious packages lingering after warnings. Treat marketplace persistence as a signal of validation weakness.

Key takeaways

• GlassWorm shows that a compromised IDE extension can become a propagation mechanism, not just a local malware event.
• The campaign also illustrates how developer accounts and extension publishing rights can be used to spread malicious payloads through trusted tooling.
• Security teams need to govern extension provenance, secret exposure, and AI coding integrations as one linked trust path.

Key terms

• Extension Supply Chain Risk: The risk that a browser extension appears trustworthy in a marketplace but later performs data collection or other malicious behavior. This combines publisher trust, permission scope, and update control, and it matters because the extension can become an identity-bearing channel into sensitive browser sessions.
• Developer Secrets Exposure: The risk that workstations and CI hosts used for building software contain reusable credentials such as SSH keys, cloud tokens, registry secrets, or signing material. In supply-chain attacks, these secrets often become the primary target because they unlock later access beyond the initial host.
• Publisher trust: Publisher trust is a policy model that allows software to run because it was signed by a trusted publisher. It reduces review overhead, but it can widen risk if the publisher or certificate lifecycle is compromised, because trust is inherited rather than newly decided for each binary.
• AI Coding Assistant Risk: AI coding assistant risk is the security exposure created when coding copilots or assistants can read code, tokens, or workspace state inside developer tools. The risk is not the model itself, but the permissions and trust relationships attached to the development session.

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.