Socket Just Identified Seventy-Three New Sleeper Extensions on Open VSX, the Marketplace That Powers Cursor, Windsurf, and Most AI Coding Tools. They Were Published Benign and Updated With Malware Through Normal Update Channels. At Least Six Have Already Activated. The Rest Are Waiting.

WHAT SOCKET FOUND

Open VSX is the open-source extension marketplace that powers VS Code-compatible editors that cannot use Microsoft's official Visual Studio Marketplace. Cursor, Windsurf, VSCodium, Eclipse Theia, and most AI-assisted coding tools rely on Open VSX as their primary extension source. The marketplace serves a developer audience that has become extremely valuable for attackers because developer machines hold API keys, cloud credentials, source code, SSH keys, and access to production systems.

Socket's April 25 research identified seventy-three impersonation extensions on Open VSX tied to the GlassWorm operation. The extensions follow a consistent pattern. Each was published by a newly created GitHub account that holds one empty repository named with an eight-character random string. The extensions themselves are clones of legitimate, popular Open VSX listings. The clone uses similar branding, similar names, and similar descriptions to the original. The only differences visible to a developer browsing Open VSX are the publisher namespace and the download counts. Both are easy to miss when installing in a hurry.

Six of the seventy-three have already been weaponized. Updates pushed through Open VSX's standard extension update mechanism delivered malicious GlassWorm payloads to every developer who had installed the extension. The remaining sixty-seven extensions are sitting in install bases waiting for the same activation. Some are classified by Socket as high-confidence sleepers based on the GitHub account signature and the cloning pattern. Others are flagged as suspicious pending further updates.

THE GLASSWORM EVOLUTION

This is the third major GlassWorm wave we have seen in six months, and the technique has evolved at each step. Tracking the evolution matters because it shows how this campaign adapts to defensive responses.

Wave one (October 2025). GlassWorm first appeared using invisible Unicode characters to hide malicious code. The technique made the malicious payload undetectable to a developer reviewing source code in their editor or terminal. The Unicode characters decoded to a loader that fetched second-stage scripts to steal tokens, credentials, and secrets. The campaign was first flagged by Koi Security.

Wave two (March 2026). Socket documented seventy-two malicious Open VSX extensions tied to GlassWorm that abused extension dependencies. Instead of embedding the loader directly in each extension, the attackers used extensionPack and extensionDependencies fields to turn benign-looking standalone extensions into transitive delivery vehicles. A clean extension would specify a dependency on a separate GlassWorm-linked extension that contained the actual malware. The benign-appearing package became a delivery system for the malicious one.

Wave three (April 2026). Socket has identified seventy-three impersonation extensions that take a different approach. The extensions are published as benign clones of popular tools, using cloned listings to build trust and gather downloads before any malicious code appears. When the attacker is ready, an update introduces the malicious payload through the normal Open VSX update channel. Each wave has had to evolve in response to defensive scanning. The October wave defeated source code review. The March wave defeated single-extension scanning. The April wave defeats publish-time security scans entirely because the malicious code does not exist at publish time.

WHY THIS MATTERS FOR AI CODING TOOLS

The Open VSX marketplace is the extension source for Cursor, Windsurf, VSCodium, Eclipse Theia, and most AI-assisted coding environments. We covered Anthropic's Model Context Protocol architectural RCE on April 21 and the LMDeploy thirteen-hour exploitation window yesterday. The architectural pattern across all three stories is consistent. The AI coding ecosystem has built an enormous developer install base in a short period, on top of supply chain infrastructure that was not engineered for this scale of value or this level of attacker interest.

A developer running Cursor with a GlassWorm-infected extension is not just losing their personal credentials. They are sitting at a workstation that holds API keys to production cloud environments, SSH keys to internal infrastructure, repository access tokens, and the full range of data their AI coding agent has been authorized to read. The extension does not need to escalate privileges. It already has them through the IDE process that loaded it.

The cascade pattern is the same one we have been documenting all month. The protected target (the developer's environment) is not directly attacked. The supply chain that the protected target depends on is. The compromise propagates through trust relationships that were never designed to bear this much weight.

THE GITHUB-HOSTED VSIX PROBLEM

The April wave includes a tactical evolution that complicates the standard defensive response. When Open VSX or another registry takes down a malicious extension, the listing disappears but the developers who already installed it are still running compromised code. GlassWorm's April variant uses GitHub-hosted VSIX files for the malicious payload itself. The Open VSX registry entry is the delivery mechanism, but the payload lives on GitHub Releases or attacker-controlled GitHub repositories.

This means takedowns of the Open VSX listings do not necessarily remove the malicious payload. A developer who installed a sleeper extension before the takedown still has the malicious extension on their system. The next update check pulls the VSIX from GitHub. The malware activates regardless of whether the registry listing has been removed.

Defenders responding to GlassWorm need to understand this. Removing the extension from the marketplace is only half the work. The other half is identifying which developers installed the extension during the dormant period and ensuring those installations are removed from local environments. Most organizations do not have the inventory to know which developers have which extensions installed across their fleet of laptops.

INDICATORS AND TECHNICAL DETAILS

WHAT DEVELOPERS AND ORGANIZATIONS SHOULD DO