Developers who use VS Code-compatible editors have a new threat to watch out for. GlassWorm malware has resurfaced in a fresh wave of attacks, this time through 73 fake extensions planted inside the OpenVSX marketplace. The extensions looked completely clean at upload. Then, after collecting installs, they received silent updates that activated hidden malware. It is a calculated tactic — and it worked.
What Is GlassWorm?
GlassWorm is a supply chain attack campaign that has been running since October 2025. It targets developer environments — specifically the extension ecosystems built around Visual Studio Code and compatible editors like VSCodium, Cursor, and Windsurf.
The campaign started with a clever trick: hiding malicious code inside invisible Unicode characters. Because the characters do not render visibly in source code, standard review tools missed the payload entirely. From there, the attackers expanded aggressively. By March 2026, a coordinated wave had compromised over 433 components across GitHub, npm, and the VS Code and OpenVSX registries.
GlassWorm malware uses the Solana blockchain as its command-and-control infrastructure. The malware pings the blockchain every five seconds for updated instructions, making it harder to block with traditional network filtering. Between November 2025 and mid-March 2026, researchers tracked 50 separate transactions used to push new payload URLs.
How the Sleeper Attack Works
The latest GlassWorm campaign introduced a technique that makes detection even harder: the sleeper extension.
Here is how it works. An attacker creates a new GitHub account — typically with one or two repositories named using a random eight-character string — and uses it to publish a cloned extension on OpenVSX. The extension is a near-perfect copy of a legitimate, popular tool. Same icon, same name format, same description. The only real differences are the publisher name and the unique extension ID.
At this stage, the extension contains no malicious code. It is genuinely harmless. But that is the point. It passes inspection and starts accumulating installs.
Then comes the update. Days or weeks later, the extension receives a routine-looking update. That update quietly introduces the payload — either by pulling a malicious VSIX package from a remote GitHub repository, loading platform-specific native binaries, or executing heavily obfuscated JavaScript that decodes and runs at runtime. By the time the malware activates, it is already installed and trusted by the editor.
Six of the 73 extensions in this latest cluster were confirmed to have activated and delivered GlassWorm malware. The remaining extensions were assessed as dormant or suspicious.
What GlassWorm Steals
Once active, GlassWorm malware targets a wide range of sensitive developer data. That includes GitHub credentials, Git tokens, npm authentication details, SSH keys, and access tokens stored in the developer environment. It also targets cryptocurrency wallet data — GlassWorm has always had financial theft as a core objective alongside credential harvesting.
The stolen credentials serve a secondary purpose beyond financial gain. Attackers use them to publish additional infected extensions under compromised accounts, which accelerates the spread of the campaign across ecosystems.
The malware also targets newer IDEs. A March 2026 update added Positron, a data-science editor from Posit, to the list of targeted platforms alongside VS Code, VSCodium, Cursor, and Windsurf.
Why This Campaign Keeps Evading Detection
GlassWorm malware has become harder to catch with each new wave, and the sleeper approach is central to that.
Security tools that scan extension source code at install time see nothing wrong because, at install time, there is nothing wrong. The malicious logic does not arrive until the update. By moving the payload outside the extension’s own code — hosted remotely on GitHub or embedded in native binaries — the attackers keep the extension itself clean for as long as it needs to be.
The use of blockchain infrastructure for command-and-control adds another layer of difficulty. Blockchain transactions are public but pseudonymous, and blocking access to the Solana network would be impractical at scale.
This combination means that scanning installed extensions for known bad code is not enough. The behavior that ultimately runs is no longer reflected in the code that gets reviewed.
What Developers Should Do
All 73 extensions in the latest cluster have been removed from the OpenVSX marketplace. But removal does not help anyone who already installed them.
Researchers recommend that affected developers rotate all secrets and credentials immediately. That means GitHub tokens, npm auth tokens, SSH keys, and any other credentials the development environment could access. A full environment cleanup is also advised.
Going forward, there are some practical steps that reduce exposure. Before installing any extension, check the publisher name carefully against the legitimate source. A mismatched publisher on an otherwise convincing-looking extension is the primary indicator of a GlassWorm clone. Low install counts and newly created publisher accounts are also red flags. When reviewing installed extensions, look at the manifest for recent additions to extensionPack or extensionDependencies fields — these are the mechanism GlassWorm uses to pull in malicious dependencies through the update path.
Relying on code review alone is no longer enough. The update and install chain matters as much as the code itself.
Final Thoughts
GlassWorm malware is a sustained, professional campaign that has evolved with each new wave. The shift to sleeper extensions represents a meaningful escalation — it exploits the one moment developers are most likely to let their guard down, which is when a trusted tool receives a routine update.
The OpenVSX marketplace has removed the known extensions, but the attackers behind GlassWorm have shown they are willing to repeat the pattern. Developers who build with VS Code-compatible editors should treat extension installs with the same scrutiny they would apply to any third-party dependency. Verify the publisher, check the install history, and watch for unexpected manifest changes after updates. In an environment where the tools themselves have become an attack surface, that level of care is no longer optional.
