The GlassWorm supply chain campaign has escalated again. Researchers have confirmed 73 new impersonation extensions on the Open VSX marketplace, with at least 6 already weaponized to deliver malware to developer environments worldwide silently.
GlassWorm is a persistent, evolving threat actor campaign targeting developer toolchains through the Open VSX registry, the primary extension marketplace for VS Code-compatible IDEs such as Cursor, Windsurf, and VSCodium. First documented in October 2025.
GlassWorm initially compromised seven OpenVSX extensions with a combined 35,800 downloads, deploying malware capable of harvesting NPM, GitHub, and Git credentials, targeting 49 cryptocurrency wallet extensions, and installing hidden SOCKS proxy servers and VNC servers to turn developer machines into criminal infrastructure.
Since then, the campaign has relentlessly evolved its delivery mechanisms to evade detection and expand its reach across the software supply chain. By March 2026, the Research Team identified a wave of 72 malicious Open VSX extensions that abused transitive extension dependencies, hiding their malicious payloads behind seemingly legitimate secondary packages.
That wave was followed by a further set of sleeper extensions that activated and began pulling GitHub-hosted VSIX malware payloads. Now, in April 2026, A new cluster of 73 additional impersonation extensions, marking what researchers describe as a consistent and systematic expansion of the GlassWorm operation.
Sleeper Extension
A sleeper extension is a threat actor-controlled imposter published before it is weaponized. These extensions appear entirely benign at first, often to build credibility, download counts, and user trust, but are later updated to deliver malware through the normal extension update path.
This technique is particularly dangerous because most security scanning tools evaluate extensions at the time of publication, not continuously after updates. What makes this latest cluster especially alarming is its patience and precision.
Each of the 73 cloned extensions was published by a newly created GitHub account with only one or two public repositories, one of which is empty and named with a random eight-character string. The extensions mimic the visual appearance of legitimate, widely used tools.
For example, Emotionkyoseparate.turkish-language-pack closely mirrors the official MS-CEINTL.vscode-language-pack-tr Turkish Language Pack, copying its globe icon, description, and Turkish-language README content, but swapping in a new publisher identity. A developer scanning the marketplace could easily miss the difference.
GlassWorm Delivers Its Payload
The April 2026 wave demonstrates a hybrid, multi-stage delivery architecture that makes detection significantly harder. Researchers identified two primary technical execution paths:
Native Binary Execution: Some extensions, such as boulderzitunnel.vscode-buddies, load platform-specific native .node binaries upon activation.
These binaries contain embedded GitHub release URLs pointing to .vsix payloads and use --install-extension commands to silently install malicious extensions across multiple IDEs, including VS Code, Cursor, and Windsurf.
Obfuscated JavaScript Loader: Other extensions, such as cubedivervolt.html-code-validate, use heavily obfuscated JavaScript that decodes at runtime to fetch .vsix payloads from GitHub releases.
These variants also include an encrypted fallback URL that is decoded at runtime, ensuring redundant delivery even if the primary payload hosts are taken down.
Earlier GlassWorm variants leveraged an even more novel technique: using Solana blockchain transaction memos as dead-drop channels for second-stage payload retrieval, executing encoded payloads in memory to avoid writing suspicious files to disk.
Across all variants, the pattern is consistent; the extension itself acts as a thin loader, shifting critical logic outside of what standard marketplace scanners typically inspect.
Three-Stage Attack Chain
Once a weaponized extension is installed, GlassWorm executes a structured, three-stage compromise:
- Stage 0: Establishes the initial infection foothold, configures infrastructure, and prepares the environment for payload delivery
- Stage 1: Downloads the core payload, harvests developer credentials from NPM, GitHub, and Git, and obfuscates malicious activity using techniques such as a hidden PowerShell persistence script (
script_zombi) and a scheduled task namedUpdateApp - Stage 2: Exfiltrates recovered credentials and sensitive data to attacker-controlled servers, compromises browser session data, installs a Node.js Remote Access Trojan (RAT) with credential-stealing modules, and achieves persistent access surviving system reboots via
HKCU\Software\Microsoft\Windows\CurrentVersion\Runregistry entries
A confirmed that post-infection, GlassWorm deploys a Ledger/Trezor hardware wallet phishing binary targeting developers with cryptocurrency devices connected to compromised machines.
Open VSX Scanning Vulnerability
A critical contributing factor to GlassWorm’s success was a now-patched vulnerability in Open VSX’s pre-publish scanning pipeline.
Socket researchers found that an attacker could flood the publish endpoint with concurrent malicious .VSIX uploads, exhausting the database connection pool and causing scan jobs to fail silently with the scanner misreading failures as clean results.
This vulnerability required only a free publisher account to exploit and was addressed in Open VSX version 0.32.0, following responsible disclosure on February 8, 2026.
The following six extensions have been confirmed as active malware delivery vehicles:
| Extension ID | Role |
|---|---|
outsidestormcommand.monochromator-theme | Confirmed malicious |
keyacrosslaud.auto-loop-for-antigravity | Confirmed malicious |
krundoven.ironplc-fast-hub | Confirmed malicious |
boulderzitunnel.vscode-buddies | Native binary loader |
cubedivervolt.html-code-validate | Obfuscated JS loader |
winnerdomain17.version-lens-tool | Confirmed malicious |
Mitigation
Given the sophistication of GlassWorm’s sleeper and transitive delivery methods, developers using Open VSX-compatible IDEs should take the following steps immediately:
- Audit all installed extensions against the confirmed IOC list and the dedicated GlassWorm for Socket.
- Verify publisher namespaces before installing any extension. Legitimate extensions from Microsoft use theÂ
MS-CEINTLÂ or official organization namespace, never newly created publisher accounts - Enable dependency monitoring to detect sleeper extension activations through the normal update path in real time
- Restrict IDE extension auto-updates in enterprise environments and enforce an extension allowlist policy
- Monitor for suspicious scheduled tasks named
UpdateAppand registry run keys added by unknown processes
FAQ
Q1: What is a GlassWorm sleeper extension?
A sleeper extension is a malicious impersonation package published to look benign before being updated to silently deliver malware through the IDE’s normal extension update path.
Q2: Which IDEs are affected by the GlassWorm April 2026 campaign?
The campaign targets VS Code, Cursor, Windsurf, and VSCodium, as well as any IDE compatible with the Open VSX extension registry.
Q3: How does GlassWorm evade detection?
It shifts payload logic into external GitHub-hosted VSIX files, native binaries, and obfuscated JavaScript with encrypted fallback URLs, so the extension’s source code alone reveals no malicious behavior.
Q4: Has Open VSX patched the vulnerability exploited by GlassWorm?
Yes, the pre-publish scanning bypass was patched in Open VSX version 0.32.0 after responsible disclosure on February 8, 2026, but sleeper extensions already published before the patch remain a risk.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
