73 Open VSX Sleeper Extensions Linked to GlassWorm Activate New Malware Campaign

The GlassWorm malware campaign has returned with a new wave of 73 sleeper extensions on the Open VSX Registry, showing how attackers are using patience and impersonation to target developers through trusted coding tools.

Socket reported that the extensions were first published as harmless-looking packages, then several were updated later to deliver malware. At least six of the 73 cloned extensions have already been activated in the latest campaign.

The activity marks another escalation for GlassWorm, a supply-chain campaign that has repeatedly abused developer extension ecosystems. In March 2026, Socket identified 72 malicious Open VSX extensions tied to GlassWorm, including packages that used transitive dependency tricks to install malicious loaders.

Attackers used harmless-looking extensions before pushing malware

Open VSX is an Eclipse Foundation-hosted registry for VS Code-compatible extensions and serves as an open alternative to Microsoft’s Visual Studio Marketplace. Developers using tools such as VSCodium, Eclipse Theia, Gitpod, and other compatible environments can install extensions from it.

In the latest GlassWorm wave, attackers created fake extensions that copied the names, icons, descriptions, and branding of legitimate developer tools. One example cited by Socket involved a fake Turkish Language Pack for Visual Studio Code, which copied the original extension’s globe icon and description while changing the publisher identity.

This sleeper approach makes detection harder. The extension can appear clean when first uploaded, gather downloads, and build visual trust before attackers push a later update that turns it into a malware delivery channel.

How the new GlassWorm campaign works

The April 2026 cluster uses two main delivery methods. Some extensions include bundled native .node binaries that act as installers and contain embedded URLs for malicious .vsix files. These payloads target VS Code-compatible environments, including VS Code and Cursor.

Other extensions rely on heavily obfuscated JavaScript. In those cases, the malicious code decodes itself at runtime, retrieves a payload from a GitHub release, and installs the malicious VSIX package through command-line paths.

This shift keeps much of the harmful logic outside the visible extension source. It also gives attackers more flexibility because they can change external payloads without changing the original package as often.

Campaign detail	What researchers found
Marketplace targeted	Open VSX Registry
Malware family	GlassWorm
New extensions tracked	73 sleeper or impersonation extensions
Confirmed activated extensions	At least 6
Main tactic	Publish clean-looking clones, then weaponize updates
Delivery methods	Native .node binaries and obfuscated JavaScript
Payload source	External VSIX files, including GitHub-hosted payloads

Why developers are high-value targets

Developer machines often contain source code, access tokens, cloud credentials, SSH keys, GitHub sessions, npm credentials, and internal project files. That makes compromised IDE extensions especially dangerous because developers usually grant them broad access inside active workspaces.

Earlier GlassWorm activity already showed the risk. Truesec reported in October 2025 that compromised OpenVSX extensions targeted GitHub, npm, Git credentials, cryptocurrency wallets, and remote access capabilities. The same campaign family has continued to adapt since then.

Microsoft’s own documentation warns that extensions can add powerful capabilities to VS Code, while its Marketplace protections include checks such as secret scanning and package integrity controls. Those protections help, but the GlassWorm case shows why developers still need to treat extensions as executable software, not simple UI add-ons.

Indicators linked to the latest activity

Security teams should review developer environments for the indicators Socket associated with the latest GlassWorm activity. These include suspicious extension publishers, fake language packs, unexpected VSIX downloads, and command-line installation activity launched by extensions.

Socket listed the following indicators in its latest research:

• Native installer binary SHA256: 1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168
• Downloaded VSIX payload SHA256: 97c275e3406ad6576529f41604ad138c5bdc4297d195bf61b049e14f6b30adfd
• Malicious GitHub hosting path: github[.]com/SquadMagistrate10/wnxtgkih
• Confirmed malicious extensions: outsidestormcommand, monochromator-theme, boulderzitunnel, and vscode-buddies

Teams should also check for recent extension updates that came from unfamiliar publishers, especially if the extension imitates a popular language pack, theme, formatter, AI coding tool, or developer utility.

What developers and security teams should do

Developers should remove suspicious Open VSX extensions and compare installed packages against trusted publisher namespaces. Similar names, cloned icons, low download counts, and new publisher accounts should raise immediate concern.

Security teams should audit VS Code-compatible environments, review extension installation logs, and block unknown extension publishers where possible. They should also monitor outbound traffic from IDE processes and investigate unexpected downloads of .vsix, .node, or obfuscated JavaScript payloads.

Recommended checks include:

• Verify the publisher before installing any extension.
• Avoid cloned tools with low download counts or recent publisher accounts.
• Review extension update history before trusting a package.
• Restrict extension installation in enterprise environments.
• Monitor GitHub-hosted payload downloads from IDE processes.
• Rotate developer credentials after suspected exposure.
• Remove unused extensions from VS Code-compatible editors.

Summary

1. Socket found 73 new Open VSX sleeper extensions linked to GlassWorm.
2. At least six extensions have already been activated to deliver malware.
3. Attackers are cloning popular developer tools and waiting before pushing malicious updates.
4. The campaign uses native binaries and obfuscated JavaScript to fetch external VSIX payloads.
5. Developers should audit installed extensions, verify publishers, and rotate credentials after exposure.

FAQ