Topic starter
02/08/2026 12:22 pm
TL;DR: 35,800 confirmed compromised installations show how GlassWorm spread through VS Code extensions, from Veracode Threat Research case work. Extension updates and publisher identities now sit on the attack path, so trust in who can distribute code matters as much as what code is reviewed.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “GlassWorm: The First Self-Propagating VS Code Extension Worm”.
Key questions
Q: Why do developer tokens and publishing credentials make supply chain worms worse?
A: Because they convert one compromised workstation into a trusted distributor.
Q: What are the signs that an extension supply chain compromise is spreading?
A: Look for unusual update patterns, new publisher activity from previously quiet accounts, unexpected token use, and outbound connections tied to unfamiliar services or infrastructure.
Q: What fails first when a self-propagating extension worm enters a developer environment?
A: The first failure is usually trust in the extension publication and update chain.
Practitioner guidance
- Audit extension trust chains Inventory installed VS Code extensions, identify inactive or unverified publishers, and remove any extension that cannot be tied to a clear ownership and review path.
- Rotate publishing and automation tokens Revoke and reissue NPM, GitHub, and marketplace tokens used on developer workstations or in pipelines, and shorten their usable lifetime where publishing is required.
- Disable blind auto-updates for extensions Require manual review or staged rollout for extension updates in higher-risk environments, especially where developer machines have access to source, build, or release systems.
Bottom line: GlassWorm shows that extension ecosystems can be used for autonomous malware propagation, not just isolated package compromise.
Glossary terms: Self-propagating worm, Non-Human Identity (NHI), Command-and-control, Extension Supply Chain Risk
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 1:22 pm
Self-propagating supply chain malware is now an identity problem, not just a code integrity problem. GlassWorm only becomes dangerous at scale because one stolen publishing token can authorise the next compromise. That changes the governance question from "is the code malicious?" to "which machine credentials can move trust across the ecosystem?" Practitioners need to manage publishing tokens as privileged identities, not convenience secrets.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
A: They need both, but neither is sufficient alone. Code review can miss hidden or obfuscated payloads, while identity controls can fail if tokens are over-scoped, long-lived, or shared across workflows. The safer model is to govern publisher identities, constrain update pathways, and inspect the content and behaviour of extensions together.
👉 Read our full editorial: GlassWorm shows how self-propagating extension worms scale