Notifications
Clear all
Topic starter
09/07/2026 12:36 pm
TL;DR: GlassWorm uses compromised Visual Studio Code extension supply chains to steal developer credentials, republish malicious extensions, and reach C2 through Solana blockchain memo fields, while Knostic says it published YARA signatures to detect the behaviour. This is a supply-chain identity problem, not just a malware problem: trust collapses when extension publishers, tokens, and review processes are all part of the attack path.
NHIMG editorial — based on content published by Knostic: GlassWorm YARA signatures and defensive implications for the VS Code ecosystem
Questions worth separating out
Q: How should security teams govern credentials that can publish software packages?
A: Treat every credential that can publish, sign, or republish software as a privileged non-human identity.
Q: Why do developer credentials create supply-chain risk beyond repository access?
A: Because those credentials often control release, signing, and marketplace distribution, not just source-code access.
Q: What do security teams get wrong about extension marketplace reviews?
A: They often assume visible code review is enough to catch malicious packages.
Practitioner guidance
- Classify publishing tokens as privileged NHIs Put npm, GitHub, OpenVSX, Git, and SSH credentials that can publish or republish code into the same governance tier as other high-risk service identities.
- Scan extension content for hidden Unicode and loader obfuscation Add Unicode normalization, invisible-character detection, and package diff checks to extension and dependency review pipelines.
- Monitor for anomalous republishing across marketplaces Correlate publishing events, token use, and extension updates across OpenVSX and adjacent marketplaces.
What's in the full article
Knostic's full research covers the operational detail this post intentionally leaves for the source:
- YARA signature logic for GlassWorm behaviours across extension loaders, credentials, and self-propagation.
- Detailed detection coverage for Solana blockchain C2, including memo-field based retrieval patterns.
- Specific indicators tied to npm, GitHub, OpenVSX, Git, and SSH credential theft.
- Repository-level examples for tuning and adapting the rules to local environments.
👉 Read Knostic's analysis of the GlassWorm VS Code extension supply-chain worm →
GlassWorm in the VS Code ecosystem: what security teams need to act on?
Explore further
09/07/2026 12:42 pm
GlassWorm is a supply-chain identity breach, not just a malware event. The worm succeeds because developer publishing credentials function as privileged non-human identities with direct distribution power. When those credentials are stolen, the attacker does not need to break the marketplace itself; they simply become a trusted publisher. Practitioners should treat extension publishers, npm tokens, and GitHub credentials as governed identities with lifecycle controls, not as background tooling secrets.
A few things that frame the scale:
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- 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.
A question worth separating out:
Q: Who is accountable when a stolen publishing token is used to spread malware?
A: Accountability sits with the team that owns the publishing identity, the platform that governs distribution, and the security function that defines revocation and monitoring requirements. In practice, governance must cover the full lifecycle of the token, from issuance to offboarding, because stale publishing access becomes an attack primitive once compromise occurs.
👉 Read our full editorial: GlassWorm shows how VS Code extensions can become worm carriers
