In October 2025, researchers at Koi Security documented GlassWorm targeting the OpenVSX marketplace through compromised developer accounts, malicious extension updates, and automatic distribution to all downstream users. The campaign has since persisted and expanded. By March 2026, researchers have identified at least 72 additional malicious Open VSX extensions and evidence of the same attack technique spreading across 151 GitHub repositories.
Further analysis from OpenSourceMalware shows the latest wave has impacted more than 433 compromised components across GitHub, npm, and VS Code/OpenVSX ecosystems. This demonstrates how GlassWorm is no longer confined to a single platform, but operates as a coordinated, multi-ecosystem supply chain attack.
At a glance, the pattern is familiar: a compromised developer account, a malicious update pushed to a legitimate extension, and silent automatic delivery to every user who has it installed. What makes GlassWorm significant is the sophistication of its evasion and propagation mechanics and what that sophistication signals about the trajectory of software supply chain attacks.
How GlassWorm operates: invisible, resilient, self-propagating
GlassWorm is not a single incident. It is an ongoing campaign built around a tightly integrated chain of techniques designed for stealth, persistence, and autonomous spread.
Invisible code injection
The attack begins with malicious payloads embedded using Unicode variation selectors: characters that do not render in code editors or during standard code review. To a developer inspecting the extension, the code appears unchanged. To the JavaScript interpreter executing it, the payload runs normally. This technique was also identified in AI-generated commits pushing malicious code to GitHub repositories, with surrounding changes, documentation tweaks, version bumps, and minor refactors crafted to appear legitimate.
Resilient command infrastructure
Once executed, GlassWorm connects to a multi-layered C2 system designed to survive takedown attempts. Its primary channel encodes payload locations in Solana blockchain transaction metadata, making infrastructure removal significantly more difficult than disrupting a conventional server. Secondary channels include direct IP-based delivery and base64-encoded URLs embedded in Google Calendar event titles.
Credential harvesting and autonomous propagation
GlassWorm collects credentials from infected developer environments, including GitHub, npm, and OpenVSX tokens, as well as cryptocurrency wallet data. Those stolen credentials are then used to compromise additional extensions and repositories, enabling the worm to spread without further attacker involvement. This self-propagating behavior is what distinguishes GlassWorm from a standard malicious package.
Full remote access
In its final stage, GlassWorm deploys a modular remote access toolkit referred to as ZOMBI. Infected systems are enrolled as proxy nodes, remotely controlled through hidden sessions, and integrated into a decentralized criminal infrastructure network.
Why this matters for automotive software supply chains
GlassWorm does not target connected vehicles directly. Its relevance to automotive cybersecurity lies in what it reveals about where the attack surface has shifted.
Modern vehicle development depends on distributed software supply chains, cloud-connected tooling, and developer environments shared across OEMs, Tier 1 suppliers, and third-party contributors. These integration points, not deeply embedded vehicle systems, are emerging as high-value targets. A single compromised developer workstation can introduce malicious code into build pipelines, expose sensitive credentials, and create pathways into backend systems that support vehicle operations.
The risk is not hypothetical. GlassWorm has already reached critical infrastructure targets: Koi Security researchers, after breaching the attacker's server, found victims that included a major government entity in the Middle East. As automotive development workflows converge with the same open-source tooling ecosystems that GlassWorm exploits, the exposure for OEMs and Tier 1 suppliers is real.
Three specific risks apply directly to automotive development environments:
- Build pipeline contamination: Malicious code injected into a developer's environment can propagate into software components before any production-stage security check is applied.
- Credential exposure: Stolen repository tokens can provide access to proprietary vehicle software, configuration files, and internal infrastructure.
- Supply chain lateral movement: Self-propagating behavior means a single compromised contributor account can spread infection across shared repositories and extension ecosystems used by multiple organizations.
Securing the invisible attack surface
GlassWorm surfaces a gap that conventional approaches are not designed to close. Signature-based detection does not catch payloads rendered invisible by Unicode manipulation. Standard software composition analysis (SCA) tools that rely on known vulnerability databases will not flag a malicious object that carries no assigned CVE. And marketplace review processes, as the GlassWorm campaign has demonstrated repeatedly, can be bypassed by attackers who first establish trust with a clean extension before pushing a malicious update.
GlassWorm shows why supply chain visibility matters. VicOne’s xZETA, an automotive vulnerability and software bill of materials (SBOM) management system, is built to surface hidden risks across the software supply chain. The real question is no longer whether development environments can be compromised. It is whether organizations have the visibility to detect threats intentionally built to remain invisible.
