GlassWorm shows how VS Code extensions can become worm carriers

At a glance

What this is: This is an analysis of GlassWorm, a self-propagating worm in the VS Code extension ecosystem that steals developer tokens, republishs compromised extensions, and uses blockchain-based command and control.

Why it matters: It matters because IDE extensions now sit inside the software supply chain and can become a credential theft and propagation channel that affects NHI governance, developer identity, and build trust.

Context

GlassWorm is a supply-chain worm aimed at the VS Code extension ecosystem, with the attack path running through extension publishing, developer credentials, and marketplace trust. In practical terms, the security problem is not just malicious code in an editor plugin, but the identity and lifecycle controls around the accounts and tokens that publish it.

The article says the worm hides loader logic with invisible Unicode characters, steals npm, GitHub and OpenVSX tokens, and then republishs compromised extensions to spread further. That makes this a governance problem for software distribution, where publisher identity and credential custody become part of the product security boundary.

For identity teams, the important point is that developer tooling has become a high-value trust layer in the same way browsers and endpoints already were. The starting position is now typical for modern extension ecosystems, not an edge case.

Key questions

Q: What breaks when a trusted VS Code extension publisher is compromised?

A: When a trusted publisher identity is compromised, the marketplace can distribute malicious code as if it were legitimate. The break is not only in code review, but in the assumption that publisher identity is trustworthy. Auto-update then turns that identity failure into rapid endpoint exposure across many developer machines.

Q: Why do compromised developer credentials accelerate supply chain compromise in cloud-native ecosystems?

A: Compromised developer credentials turn one infected package or workflow into a distribution channel for more malware. When tokens can publish packages or write to repositories, attackers can reuse legitimate access to spread malicious code with little friction. This creates a rapid cascade across maintainers, package versions, and downstream consumers, especially where CI/CD has broad standing trust.

Q: What are the signs that an extension ecosystem is being abused for propagation?

A: Watch for suspicious republishing activity, new versions that appear after unusual credential use, hidden text or obfuscated logic in extension files, and outbound control traffic from developer tools. Those signals suggest the distribution path itself has been turned into the malware delivery mechanism.

Q: How should security teams govern code distribution tokens and marketplace access?

A: Treat marketplace access as a privileged pathway, not a normal developer convenience. Limit who can publish, shorten token lifetime where possible, separate build from release duties, and require detection for anomalous republishing. If an account can push code to a trusted marketplace, it needs governance like any other privileged identity.

Technical breakdown

How extension supply chains become a worm carrier

A VS Code extension marketplace is not just a code distribution channel. It is an identity-backed publishing system in which a token, an account, and a package registry together authorize new software to reach users. GlassWorm abuses that trust by moving from a compromised extension into the publisher credentials needed to republish malicious updates. Once the attacker controls the publishing path, the extension itself becomes a delivery mechanism for propagation rather than a one-time payload. Practical implication: treat extension publishing rights as part of the software supply chain, not as a routine developer convenience.

Practical implication: Classify extension publishers and their tokens as supply-chain assets with explicit ownership, review, and revocation control.

Why invisible Unicode bypasses review and detection

The article says GlassWorm hides loader logic with invisible Unicode variation selectors. That matters because code review, static inspection, and simple pattern matching all assume the visible text of a file reflects its behaviour. When malicious logic is encoded in ways that are hard to see in a standard editor, reviewers can approve code that does not look suspicious at all. This is not a sophisticated exploit of the runtime alone. It is an abuse of human review assumptions and tooling blind spots. Practical implication: detection must account for text normalization and Unicode-aware inspection before extension publication.

Practical implication: Normalize source text and scan for hidden characters before approving or republishing any extension.

How stolen developer tokens enable self-propagation

The worm steals npm, GitHub, OpenVSX and related credentials, then uses those credentials to compromise and republish extensions. That pattern turns credential theft into propagation logic. The stolen token is not only a path to code access; it is the authorization primitive that lets the attacker reach new publishers and new installs. The article also notes Solana-based memo fields for C2 and fallback Google Calendar C2, showing that the campaign mixes theft, distribution, and control channels in one chain. Practical implication: credential scope and publishing permissions must be tightly separated from general developer access.

Practical implication: Limit publishing tokens to the smallest viable scope and revoke any credential that can write to extension marketplaces.

Threat narrative

Attacker objective: The attacker aims to turn trusted developer tooling into a propagation channel that steals credentials, spreads malicious extensions, and preserves remote control over infected environments.

1. Entry occurs through compromised or malicious VS Code extensions distributed across OpenVSX and related supply chains.
2. Credential harvesting follows, with the worm stealing npm, GitHub, OpenVSX, Git and SSH credentials from infected developer environments.
3. Escalation happens when stolen publishing credentials are used to republish compromised extensions and spread the worm to new victims.
4. Impact is sustained propagation, wallet-targeting activity, and blockchain-based command and control that keeps the malware operational.

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.
• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

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

Extension marketplaces have become identity infrastructure: once a publishing token can place code into a trusted ecosystem, the marketplace is no longer a neutral distribution layer. The security question moves from package integrity alone to who can publish, under what lifecycle conditions, and with what revocation authority. That makes publisher identity and token governance central to software supply-chain risk.

Invisible-character stealth is a governance failure, not just an evasion trick: if review processes assume humans can reliably inspect source text, attackers will encode malicious logic in ways that defeat that assumption. This is a control gap in review design, not only a malware feature. Practitioner teams should treat text-normalization blind spots as a first-class supply-chain risk.

Credential custody now defines propagation potential: GlassWorm shows that developer tokens are not merely access artifacts, they are the mechanism by which compromised software can re-enter the ecosystem. The named concept here is credential-to-publishing collapse, where the same secret authorizes both development work and malicious redistribution. That demands separate governance for authoring, publishing and marketplace release rights.

Blockchain C2 in this context is operational camouflage, not the primary lesson: the deeper issue is that the worm survived because trust in extension signing, publishing and developer identity was already too broad. The attack works by chaining legitimate ecosystem privileges into malicious distribution. Practitioners should re-evaluate where their supply-chain controls stop and their identity controls begin.

Need-to-know for code distribution must extend to AI-assisted development environments: the article's point that coding tools are high-value targets means IDE ecosystems are now part of the enterprise attack surface. The governance boundary has shifted from endpoint hardening to software-authoring trust, and that is where review, token scope and provenance controls now matter most.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Credential-to-publishing collapse: once a developer token can both access tools and republish software, the identity boundary has failed. Programmes that still treat publishing rights as ordinary development access will miss the point of this attack class.

Extension ecosystems now need the same lifecycle thinking applied to other non-human identities: ownership, scope, review, revocation and offboarding. The threat is not just malicious code, but durable rights that let compromised accounts re-enter a trusted channel.

For practitioners

• Harden extension publishing permissions Separate extension publication rights from day-to-day developer credentials, and require explicit approval for tokens that can push to marketplaces or republish packages.
• Scan for hidden Unicode before release Add Unicode normalization and hidden-character checks to pre-publish review so invisible selectors and similar obfuscation cannot bypass code inspection.
• Inventory developer tokens with write access Map every npm, GitHub, OpenVSX, Git and SSH credential that can influence software distribution, then revoke any token that is no longer essential.
• Treat marketplace republishing as a separate risk tier Apply stronger change control to any account that can overwrite or republish extension artefacts, because that path turns one compromise into ecosystem spread.
• Monitor for nonstandard C2 channels in developer tooling Look for blockchain memo use, unusual API calls, and fallback collaboration-app signalling from systems that should only build, sign or publish code.

Key takeaways

• GlassWorm is a supply-chain worm, not a simple extension malware case, because it uses developer identities to spread through trusted marketplaces.
• The article shows how stolen tokens, hidden Unicode, and republishing rights combine into a repeatable propagation pattern across VS Code ecosystems.
• The control failure is the same one many teams miss in other NHI programmes: when publishing rights are too broad, one compromised credential can become an ecosystem-wide distribution 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.
• Legacy publishing token: A long-lived authentication credential used to publish or manage packages in a repository. In NHI governance, the risk is not only theft but persistence, because an unrevised token can remain valid after newer controls are added and can bypass the intended identity path.
• Unicode Stealth: Unicode stealth is the use of special or invisible characters to hide malicious logic, alter how code appears in review, or bypass simple pattern checks. It exploits the gap between what a reviewer sees and what the parser or runtime actually processes.
• Credential-to-Publishing Collapse: Credential-to-publishing collapse describes the failure mode where the same secret both grants development access and authorises software release. In that state, stolen credentials can move directly from identity compromise to ecosystem propagation, which is why publishing rights need separate governance.

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.