GlassWorm Campaign Uses 73 Malicious Open VSX Extensions

Key Takeaways

• The GlassWorm supply chain attack has intensified with the discovery of 73 new “sleeper” extensions on the Open VSX marketplace.
• Attackers are now using a sophisticated method where initially benign extensions are weaponized later via updates, making detection more challenging.
• These malicious extensions mimic popular tools, leveraging fake publisher names and cloned aesthetics to trick developers into installation.
• The campaign employs both native binaries and heavily obfuscated JavaScript to deliver malicious payloads, often fetching additional .vsix files for IDEs like VS Code and Cursor.

GlassWorm Campaign Escalates with 73 New Malicious Open VSX Extensions

The GlassWorm supply chain attack targeting the Open VSX marketplace has significantly expanded, with researchers uncovering an additional 73 “sleeper” extensions designed to compromise software developers. This latest wave, identified in April 2026, signals a concerning evolution in how threat actors are deploying malware within the developer ecosystem.

This discovery follows a substantial wave of 72 malicious Open VSX extensions linked to the GlassWorm operation, which were documented in March 2026. While earlier iterations of the campaign exploited extension dependency features to silently install malicious loaders, the April 2026 cluster reveals more advanced tactics aimed at evading security scans.

The “Sleeper” Extension Strategy

A “sleeper” extension refers to a deceptive package published by threat actors that initially appears harmless. These extensions are designed to build trust and credibility, accumulating downloads before they are weaponized. Attackers typically create new GitHub accounts to publish these cloned versions of legitimate, popular development tools.

For instance, one example involved attackers creating a fake Turkish Language Pack for Visual Studio Code. This malicious extension meticulously mimicked the legitimate version, copying the globe icon and description, with the only discernible difference being a swapped publisher name. This tactic aims to deceive developers who might not scrutinize publisher details closely.

Once developers install these seemingly benign tools, the attackers bide their time before pushing a software update that delivers the malicious payload. At least six of the 73 newly discovered extensions have already been activated to deploy their intended malware.

Evolving Delivery Mechanisms

The latest iteration of the GlassWorm campaign demonstrates a refined approach to payload delivery. The extension itself now functions primarily as a thin loader, designed to fetch external payloads rather than containing the malicious code directly within its source. This technique significantly reduces the likelihood of immediate detection by security tools.

The campaign employs two primary execution methods:

• Native Binaries: This method involves bundling .node files, hidden within the extension’s code. A simple JavaScript file then executes this binary, which contains embedded URLs used to download additional malicious .vsix files. These payloads are intended for installation within Integrated Development Environments (IDEs) such as VS Code and Cursor.
• Obfuscated JavaScript: In this approach, the malicious logic is heavily obfuscated and does not rely on bundled binary files. The code decodes itself at runtime, subsequently retrieving a malicious .vsix payload from a GitHub release and installing it via command-line paths.

Indicators of Compromise

Security teams should actively monitor for the following indicators associated with the GlassWorm campaign:

• Native Installer Binaries (SHA256): 1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168
• Downloaded VSIX Payload (SHA256): 97c275e3406ad6576529f41604ad138c5bdc4297d195bf61b049e14f6b30adfd
• Malicious GitHub Hosting: github[.]com/SquadMagistrate10/wnxtgkih
• Confirmed Malicious Extensions: outsidestormcommand, monochromator-theme, boulderzitunnel, vscode-buddies

What You Should Do

According to the Socket Research Team, developers must exercise extreme caution when installing extensions from the Open VSX marketplace. Practical mitigation steps include:

• Verify Publisher Namespaces: Always meticulously check the publisher name of any extension, ensuring it matches the official or expected publisher.
• Inspect Download Counts and Reviews: While not foolproof, higher download counts and consistent positive reviews can be indicators of legitimacy, though attackers are trying to subvert this.
• Scrutinize Extension Permissions: Understand the permissions an extension requests and question any that seem excessive for its stated functionality.
• Use Security Tools: Employ security solutions that scan for malicious code in development environments and monitor for suspicious network activity.
• Stay Updated: Keep development tools and IDEs updated to their latest versions to benefit from security patches.
• Isolate Development Environments: Consider using virtualized or containerized development environments to limit the potential impact of a compromise.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.