On 30 January 2026, the Open VSX marketplace faced a notable software supply chain attack: four Visual Studio Code extensions published under the developer nickname oorzc received malicious updates containing the GlassWorm malware loader. These extensions had appeared legitimate for a long time, with some in use for more than two years before the injected code was added.
Compromised Open VSX extensions and stolen publisher credentials
According to researchers at Socket, attackers compromised the extension publisher’s account and pushed new versions embedding malicious functionality. The Open VSX security team believes access was likely obtained via a leaked access token or other credential theft or substitution technique.
The tainted versions of the four extensions were quickly removed from Open VSX once anomalous behavior was detected. However, the fact that malicious updates were delivered as routine releases from a previously trusted account underscores how exposed extension ecosystems and the software supply chain become when a legitimate maintainer is compromised.
How the GlassWorm malware operates inside VS Code extensions
Runtime decryption of the payload to evade static analysis
The malicious releases integrated a GlassWorm loader whose role is to silently decrypt and execute an embedded payload at runtime. In the extension’s source code, the harmful logic is heavily obfuscated or encrypted, making traditional static analysis significantly harder. The real behavior is revealed only when the extension runs on the developer’s machine.
EtherHiding technique for resilient C2 communication
GlassWorm employs an evasion method known as EtherHiding. In practice, this means the malware does not store fixed command-and-control (C2) server addresses. Instead, it retrieves them dynamically from external, often decentralized or hard-to-take-down services. Blocking a single domain or IP address is therefore not enough; the operators can rapidly rotate their infrastructure without pushing a new malware build.
Primary targets: developer credentials and cryptocurrency wallets
Once activated, GlassWorm focuses on data theft inside the developer environment, with a particular emphasis on macOS systems. The payload is designed to locate and exfiltrate highly sensitive information that can be monetized or used in further attacks.
1. Authentication data and access tokens in developer tooling. GlassWorm inspects configuration files for package managers such as npm, searching specifically for the _authToken parameter. It also hunts for GitHub authentication artifacts and other access tokens. With these credentials, attackers may access private repositories, CI/CD platforms and secret stores, or even tamper with release pipelines and published artifacts.
2. Cryptocurrency wallets and related artifacts. The malware scans the system for files and traces associated with cryptocurrency wallets, aiming to collect information sufficient to gain control over digital assets. This continues a broader trend of developer-focused malware doubling as crypto stealer.
Victim profiling and avoidance of Russian-language environments
Before fully activating, GlassWorm performs environment profiling. Among other checks, it examines the system locale. If the operating system is configured for Russian language, the malware refrains from executing its main malicious logic. Such geofencing is common in financially motivated campaigns and is often interpreted as an attempt to reduce legal and law-enforcement risks in certain jurisdictions.
A key difference from earlier GlassWorm incidents is the distribution vector. Previous campaigns relied on typosquatting and brandjacking — publishing look‑alike extensions with names similar to popular plugins. In this case, attackers abused an already established, reputable publisher account, greatly increasing user trust and reducing suspicion around new updates.
Impact on VS Code ecosystem and software supply chain security
The Open VSX incident illustrates how a single compromised developer account can cascade through the entire software supply chain. IDE extensions effectively run with wide privileges in a highly trusted environment that often contains API keys, CI/CD tokens, SSH keys, secrets and proprietary source code.
This aligns with broader industry data. ENISA has reported a multi-fold increase in software supply chain attacks in recent years, and Sonatype’s State of the Software Supply Chain reports highlight a several-hundred‑percent growth in open source ecosystem attacks since 2019. Package registries (npm, PyPI), IDE extension marketplaces and build systems remain prime targets because they provide mass distribution through trusted channels.
Security recommendations for extension authors, DevSecOps and marketplaces
For extension developers and maintainers, the priority measures include:
— Enforce multi-factor authentication (MFA/2FA) on all accounts used to publish packages and extensions.
— Regularly rotate and revoke access tokens, limiting both their lifetime and scope according to the principle of least privilege.
— Store secrets in dedicated secret management systems, not in config files or environment variables readily accessible to tools and plugins.
— Closely monitor release history and artifacts for unexpected changes, especially if a new version appears without a corresponding, intentional commit trail.
For development and DevSecOps teams, it is advisable to:
— Maintain and periodically review a whitelist of trusted VS Code/Open VSX extensions approved for use in the organization.
— Implement SBOM (Software Bill of Materials) analysis and continuously monitor dependencies for vulnerabilities and compromise signals.
— Deploy EDR and behavioral monitoring capable of detecting suspicious IDE and plugin activity, such as unusual outbound connections or interaction with crypto wallet files.
For extension marketplaces and repositories, strengthening both automated and manual review is critical. This includes static and dynamic code analysis, behavioral models for detecting anomalous updates, and robust account protection and verification mechanisms for publishers.
The GlassWorm incident in Open VSX is a reminder that even long‑trusted VS Code extensions can be turned into attack tools overnight. Organizations should regularly audit installed plugins, remove unused ones, reinstall them from verified sources and tighten policies around tokens and secrets. Treating extensions and packages as core components of the software supply chain rather than optional add‑ons significantly reduces the likelihood of successful compromise in similar future campaigns.
