GlassWorm shows how self-propagating extension worms scale

At a glance

What this is: GlassWorm is a self-propagating VS Code extension worm that hides malicious code, steals developer credentials, and spreads through package and extension ecosystems.

Why it matters: It matters because development tooling now carries NHI and secrets risk, so IAM, PAM, and secrets governance teams need to treat extension ecosystems as identity-bearing infrastructure.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Veracode's analysis of the GlassWorm VS Code extension worm

Context

GlassWorm matters because it combines supply chain compromise with identity abuse. A malicious extension can now hide from review, update itself through trusted channels, and then steal the credentials that let it keep spreading. For development teams, the problem is no longer just code provenance. It is also the trust placed in extension publishers, update mechanisms, and the non-human identities that connect developer tooling to package registries.

In practical terms, this is a governance failure across software supply chain and NHI control planes. Tokens for NPM, GitHub, and OpenVSX are not passive artifacts. They are credentials with enough privilege to move laterally across ecosystems, and once they are abused, the attack becomes self-sustaining. That makes GlassWorm relevant to IAM, PAM, secrets management, and DevSecOps programmes alike.

Key questions

Q: What breaks when VS Code extensions can self-propagate through registry credentials?

A: The main failure is trust in the publishing identity. Once an extension can steal tokens and reuse them automatically, the registry becomes a propagation channel rather than a controlled software source. Security teams need to treat publishing credentials as high-impact non-human identities and limit their scope, lifetime, and reuse.

Q: Why do developer toolchains create unusual NHI and secrets risk?

A: Developer toolchains connect multiple identity systems, package registries, and automation paths, so one token can unlock several downstream actions. That makes secrets in IDEs, CI pipelines, and publishing workflows especially attractive to attackers. The risk is not only theft, but credential reuse across trusted ecosystems.

Q: What do security teams get wrong about extension review and code inspection?

A: They often assume human review can catch malicious intent before release. GlassWorm shows that invisible characters, obfuscation, and auto-update paths can bypass that assumption. Teams need automated inspection that normalises content, checks publisher trust, and validates behaviour after installation.

Q: Which frameworks are most relevant when managing self-propagating supply chain worms?

A: MITRE ATT&CK helps map credential access, persistence, and lateral movement, while OWASP Non-Human Identity Top 10 highlights the governance of publishing tokens and registry credentials. Teams should align controls to both attack behaviour and identity lifecycle, not to code review alone.

Technical breakdown

Invisible Unicode obfuscation in VS Code extensions

GlassWorm hides malicious logic using invisible Unicode and Private Use Area characters, so the code that executes is not the code a reviewer sees. This is a form of source-level deception, where the payload is structurally present but visually absent in editors and diffs. Standard manual review and simple signature checks struggle when the malicious content is encoded in characters that are easy to miss and hard to normalise consistently across tooling. The practical effect is that code inspection loses much of its value unless the pipeline normalises and sanitises text before analysis.

Practical implication: enforce Unicode normalisation and static analysis that flags invisible or non-standard characters before extension publication.

Self-propagation through registry credentials

The worm’s spread depends on harvested NPM tokens, GitHub credentials, and OpenVSX access tokens. Those are non-human identities with enough authority to publish or modify downstream packages, so compromise of one credential can become compromise of many artifacts. This is why the attack behaves more like credential-enabled replication than classic malware infection. Once the attacker owns a publishing identity, the malware can extend its reach without needing fresh manual intervention at each step.

Practical implication: bind registry publishing rights to tightly scoped, short-lived credentials with explicit approval and rotation controls.

Backup command and control through legitimate services

GlassWorm uses Solana blockchain transaction memos as primary C2 and Google Calendar as backup C2, which makes the infrastructure harder to block without breaking legitimate services. This is a common evasion pattern in modern malware: hide control traffic inside systems that defenders are reluctant to disrupt. The attack also demonstrates that C2 no longer needs obvious malicious hosting. It can ride on decentralised or trusted SaaS infrastructure, where detection must rely more on behavioural analysis than domain blocking.

Practical implication: inspect outbound behaviour and registry activity together, because trusted SaaS usage can mask the command path.

Threat narrative

Attacker objective: The attacker’s objective is to build a self-sustaining distribution channel that steals credentials, expands infection, and turns developer systems into operational infrastructure.

1. Entry occurs when a developer installs or updates a compromised VS Code extension from a marketplace that auto-updates by default.
2. Credential access follows as the worm harvests NPM tokens, GitHub credentials, and OpenVSX access tokens from the infected environment.
3. Escalation happens when those stolen credentials are reused to publish or compromise additional extensions and packages, turning each victim into a new spread point.
4. Impact is broad ecosystem contamination, remote access, wallet draining, and loss of trust in developer tooling and registry identities.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.

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

NHI Mgmt Group analysis

Self-propagating supply chain malware turns developer credentials into propagation infrastructure. GlassWorm is not just another malicious extension. It shows that a single compromised publishing identity can become a distribution mechanism across registries and marketplaces. That shifts the control problem from detecting one bad artifact to governing the credentials that make artifact publication possible. For identity teams, the lesson is that registry tokens are non-human identities with blast radius, not mere API secrets.

Invisible-code attacks expose a review gap, not only a malware gap. When malicious logic can disappear from the editor view through Unicode manipulation, the weak point is the assumption that human inspection can reliably detect intent. This is why code review alone is insufficient for extension ecosystems. Normalisation, policy enforcement, and automated content inspection must happen before trust is granted. Practitioners should treat invisible-character abuse as a control design issue, not a niche evasion trick.

Credential reuse across ecosystems is the named concept here: registry trust chaining. GlassWorm moves from one compromised identity to another by abusing the trust links between VS Code marketplaces, NPM, GitHub, and backup C2 services. That chaining makes governance hard because each platform appears separate while the identity layer is connected. The practical consequence is that teams need to manage publishing rights, token scope, and update trust as one system rather than four disconnected controls.

Development tooling now sits inside the identity perimeter. The worm only becomes dangerous at scale because extension ecosystems automatically update and because credentials inside developer environments are high-value identities. That means software supply chain security and NHI governance are converging. The organisations that continue to treat registry tokens as low-risk operational artifacts will miss the real control point, which is identity lifecycle and delegated privilege.

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.
• From our research: For a broader breach pattern, see The 52 NHI breaches Report for repeated examples of credential exposure and reuse across non-human identities.

What this signals

Registry trust chaining will become a more common failure mode as attackers combine publishing credentials, auto-update channels, and trusted SaaS infrastructure into one propagation path. That means program owners need to think about extension marketplaces and package registries as identity systems, not just distribution systems. Teams can map these risks against the MITRE ATT&CK Enterprise Matrix to understand where credential access turns into lateral movement.

The control question is shifting from whether an extension is malicious to whether the identity used to publish or update it is governed tightly enough to stop automated spread. That is a different operational problem. It requires publisher attestation, token lifecycle management, and behavioural monitoring across developer tooling, not only scanning at commit time.

Where an organisation already manages machine identities well, the next step is to extend that discipline into developer ecosystems. The same lifecycle logic that applies to service accounts applies to registry tokens and publishing identities. Teams that ignore this overlap will keep treating supply chain incidents as software problems when the real weak point is delegated access.

For practitioners

• Inventory and normalise extension content Scan VS Code extensions and related packages for invisible Unicode, Private Use Area characters, and other obfuscation tricks before approval. Add text normalisation to your pipeline so reviewers and scanners see the same payload.
• Lock down registry publishing identities Restrict NPM, GitHub, and OpenVSX publishing rights to short-lived, tightly scoped credentials with strong approval workflows. Treat every publishing token as a high-risk non-human identity.
• Rotate exposed developer credentials immediately If any affected extensions were installed, rotate NPM tokens, GitHub credentials, and related access tokens without waiting for user confirmation. Assume the worm’s value comes from reuse across ecosystems, not just the first foothold.
• Review auto-update trust settings Reassess whether extension auto-updates should remain enabled for all developer groups. Where manual approval is feasible, require review of update provenance, publisher reputation, and behavioural changes in the package.
• Correlate registry activity with endpoint telemetry Use endpoint and registry monitoring together to spot suspicious publish, install, or update sequences that move faster than normal developer workflows. The same account that installs the extension may later be used to spread it.

Key takeaways

• GlassWorm shows that extension ecosystems can now behave like self-propagating malware infrastructure, not just distribution channels.
• The attack’s scale and speed make leaked registry credentials a governance problem, because published tokens can be reused across multiple identity systems.
• The limiting control is not code review alone, but lifecycle governance for publishing identities, update trust, and obfuscation-aware inspection.

Key terms

• Self-propagating worm: A self-propagating worm is malware that automatically spreads from one compromised system to another without waiting for a human operator to copy it. In software supply chains, propagation often happens through trusted accounts, package registries, or update channels that the worm can reuse.
• Registry token: A registry token is a credential that authorises publishing, modifying, or accessing software packages in a registry or marketplace. It behaves like a non-human identity when it can trigger automation, so compromise of the token can let an attacker alter downstream software at scale.
• Unicode Obfuscation: The use of lookalike characters, invisible separators, or bidirectional controls to make text appear benign while changing how systems interpret it. In identity and security workflows, this breaks visual review and text-based detections unless controls inspect character classes and normalized behavior.
• Trust chaining: Trust chaining is the reuse of confidence from one system to another, such as a marketplace trusting a publisher token or a package trusting an update path. Attackers exploit those links to move laterally across ecosystems while each individual step appears legitimate.

What's in the full article

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

• How the GlassWorm payload hides in Unicode and Private Use Area characters during review
• What the malicious extension does after installation, including token theft and propagation
• How the backup Google Calendar C2 path works in practice and why it evades simple blocking
• Which developer actions Veracode recommends for extension audits and credential rotation

👉 Veracode's full post covers the attack chain, credential theft, and developer-side mitigation steps

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. It helps practitioners connect identity controls to the wider security programme they already run.