TL;DR: GlassWorm is a self-propagating malware campaign that spread through compromised developer accounts and the OpenVSX registry, targeting VS Code environments and AI coding assistants while stealing developer credentials, npm tokens, and crypto wallets, according to Knostic’s source analysis. The incident shows that IDEs have become privileged supply-chain targets, not just developer tools.
NHIMG editorial — based on content published by Knostic: GlassWorm malware in VS Code extensions and AI coding assistants
Questions worth separating out
Q: How should security teams respond when a malicious IDE extension appears in a developer marketplace?
A: Contain the publisher account first, then remove or disable the extension, invalidate any tokens exposed to that environment, and review downstream package or cloud access for reuse.
Q: Why do compromised developer extensions create more risk than ordinary endpoint malware?
A: Because they can inherit trust from the developer account, reach package registries, and expose secrets that are valid outside the workstation.
Q: What do teams get wrong about securing AI coding assistants?
A: They often focus on model behaviour while ignoring the extension and registry layer that feeds the assistant.
Practitioner guidance
- Revoke publisher trust for compromised extension accounts Quarantine and revoke any developer account that can publish to extension or package registries until ownership, signing, and recovery are verified.
- Scan developer endpoints for reusable secret material Search workstations and CI-connected developer environments for npm tokens, cloud API keys, and wallet material that could be reused after extension compromise.
- Limit extension installation to allowlisted sources Restrict IDE and AI coding assistant extensions to approved registries or internal repositories where package provenance can be checked.
What's in the full article
Knostic's full article covers the operational detail this post intentionally leaves for the source:
- The specific OpenVSX propagation pattern and how compromised developer accounts were used to keep malicious extensions moving.
- The malware’s loader-hiding methods, including invisible Unicode and PUA characters, which matter for detection engineering.
- The extension listings that remained live after warnings, showing where marketplace validation failed.
- The practical detection workflow demonstrated by Kirin when an infected extension is installed.
👉 Read Knostic's analysis of GlassWorm in VS Code extensions →
GlassWorm in VS Code extensions: what security teams need to know?
Explore further
Identity trust in developer ecosystems is now a supply-chain control problem, not just an endpoint problem. GlassWorm shows that extension registries can become identity distribution systems when they are tied to compromised publisher accounts. The malware does not need novel exploitation of the IDE itself if it can inherit trust through the account that publishes to the marketplace. Practitioners should treat publisher identity, package integrity, and installation trust as one governance surface.
A few things that frame the scale:
- 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, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How can organisations reduce the blast radius of secrets stolen from developer tools?
A: Scope each secret to one function, reduce its lifetime, and remove broad publish or deploy permissions from developer-held tokens. The goal is to make any stolen credential unusable outside a narrow workflow. Shared tokens with package-publishing or cloud-admin reach create the widest downstream exposure.
👉 Read our full editorial: GlassWorm shows how compromised IDEs extend AI coding risk