73 Open VSX Sleeper Extensions Linked to GlassWorm Show New Malware Activations

Socket is tracking cloned Open VSX extensions tied to GlassWorm, with several updated from benign-looking sleepers into malware delivery vehicles.

Apr 24, 2026

By Socket Threat Research Team (co-authored by Kirill Boychenko)

The GlassWorm campaign targeting Open VSX continues to escalate. Socket is now tracking a new cluster of 73 impersonation extensions connected to the same sleeper-extension activity reported in March 2026. Beginning in April 2026, and continuing as of this writing, additional cloned versions of popular code extensions have appeared on the Open VSX marketplace. These extensions did not initially contain malware, but they were published by newly created GitHub accounts with only one or two public repositories. In each case, one repository is empty and named with an eight-character string.

A sleeper extension or package is a threat actor-controlled imposter that is published before it is weaponized. It may appear benign at first, often to build trust, downloads, or credibility, but can later be updated to deliver malware through the normal update path.

At least six of these extensions have already been activated to deliver malware, while the remaining extensions appear to be high-confidence sleepers or related suspicious extensions. This count may change as new updates continue to appear, but the pattern is consistent with earlier GlassWorm waves: cloned or impersonating extensions are first published without an obvious payload, then later updated to deliver malware through the normal extension update path.

This activity follows Socket’s previous reporting on GlassWorm’s shift toward sleeper and transitive delivery techniques, including extensions that appeared benign at publication before later adding malicious dependencies or loaders. In March 2026, Socket documented 72 malicious Open VSX extensions tied to GlassWorm’s abuse of extension relationships. That wave was followed by another set of sleeper extensions that activated and began pulling GitHub-hosted VSIX malware. For this latest cluster, Socket has marked the tracked extensions to protect users while analysis continues.

We are tracking the affected extensions associated with this supply chain attack campaign on our dedicated GlassWorm v2 page: https://socket.dev/supply-chain-attacks/glassworm-v2

Update: April 29, 2026: Activation Wave via Transitive Delivery

Since publication of this blog post, we have observed an additional activation wave leveraging the extensionPack transitive-delivery pattern we saw being weaponized back in March.

Summary

Twenty-three new versions across 22 copycat extensions on Open VSX, all with clean prior versions, were pushed on April 29 across two clusters.
An early pair was published at 18:15–18:16 UTC.
A main burst of 21 version drops landed between 19:29 and 19:34 UTC.

Seventeen of the new versions declare an extensionPack entry pointing at blockstoks.easily-gitignore-manage.

The remaining five did not pull a payload and remain in a sleeper state at time of writing, but cluster with the others on publishing time, account characteristics, and naming.

blockstoks.easily-gitignore-manage itself, however, was already gone. Socket disclosed blockstoks.easily-gitignore-manage as a GlassWorm-linked malicious extension on March 13, 2026. It was removed from Open VSX on April 27, 2026, approximately 52 hours before this activation wave landed, suggesting that the activated host extensions’ extensionPack references were dead on arrival.

We thank the Eclipse Foundation for taking swift action and removing the extension before the campaign reached its activation phase.

The fact that the threat actor pushed activations referencing an extension two days after its removal is itself an operational signal: it suggests the activation pipeline is automated and does not validate puller liveness against the marketplace before publishing host updates.

Activated Host Extensions (April 29, 2026)

New Sleeper Extensions in the Same Wave

Cloned Listings Designed to Look Legitimate

The impersonation pattern is visible in the way these extensions present themselves on Open VSX. One example is Emotionkyoseparate.turkish-language-pack, which closely mirrors the legitimate MS-CEINTL.vscode-language-pack-tr listing for the Turkish Language Pack for Visual Studio Code. The clone uses the same globe icon, similar naming, the same description, and copied Turkish-language README content, while swapping in a new publisher and unique identifier.

The difference is subtle enough that a developer browsing quickly could miss it. The legitimate extension is published under the expected MS-CEINTL namespace and shows 150K downloads, while the impersonation appears under a newly created publisher with far fewer downloads but otherwise familiar branding. This is the core social engineering pattern behind the latest GlassWorm cluster: cloned listings create enough visual trust to attract installs before any malware is introduced.

Delivery Moving Beyond the Extension Source

In our previous disclosure of the latest wave of Open VSX extensions in the GlassWorm campaign, we documented a shift away from embedding the loader directly in each extension toward abusing extensionPack and extensionDependencies for transitive delivery. This allowed extensions that did not contain any malicious code on their own to install a separate malicious component, often disguised as a utility tool.

We then observed sleeper extensions that activate via updates and retrieve payloads from external sources, including VSIX packages hosted on GitHub. Earlier variants also used Solana transaction memos as a dead-drop channel for runtime payload retrieval, where encoded second-stage payloads were fetched and executed in memory. In those cases, the malicious behavior was still tied to code associated with a specific extension or dependency.

In this latest wave, delivery spans these approaches. Some variants rely on external payload retrieval, others rely on bundled native binaries, including reused installer components seen in prior GlassWorm activity, but the common pattern is that the extension itself acts as a thin loader. The extension’s source code alone no longer reflects the behavior that ultimately runs. By shifting critical logic outside of what tools typically scan, and spreading it across multiple delivery mechanisms, the threat actor increases the likelihood of evading detection.

Example: Native Binary Execution Path

To make this concrete, let us look at the extension’s activation code in boulderzitunnel.vscode-buddies, which simply loads a platform-specific native module and invokes an install() function:

  
const platforms = { win32: "./bin/win.node", darwin: "./bin/mac.node" };
const target = platforms[process.platform];
if (target) {
  const { install } = require(target);
  install();
}

The core logic is implemented in the bundled .node binary, not the JavaScript. These binaries contain embedded GitHub release URLs to .vsix files and include installation logic (e.g., --install-extension) targeting multiple IDEs such as VS Code, Cursor, and Windsurf.

Example: Obfuscated Runtime Payload Retrieval

Other variants implement the same pattern entirely in JavaScript, without relying on bundled binaries (e.g., cubedivervolt.html-code-validate). In these extensions, the activation code contains heavily obfuscated code that decodes at runtime to retrieve a .vsix payload from a GitHub release.

The code resolves CLI paths for multiple editors, including VS Code, Cursor, Windsurf, and VSCodium, and installs the downloaded extension using commands such as --install-extension. Some variants also include an encrypted fallback URL that is decoded at runtime.

This approach achieves the same outcome as the binary-based variant, but keeps the delivery logic in obfuscated JavaScript. The extension acts as a loader, while the payload is retrieved and executed after activation.

Indicators of Compromise (IOCs)

Native Installer Binaries (SHA256)

1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168
4ebfe8f66ca7e9751060b3301b5e8838d6017593cdae748541de83bfa28183bd

Downloaded VSIX Payload (SHA256)

97c275e3406ad6576529f41604ad138c5bdc4297d195bf61b049e14f6b30adfd

GitHub Payload Hosting

github[.]com/SquadMagistrate10/wnxtgkih
github[.]com/francesca898/dqwffqw
github[.]com/ColossusQuailPray/oiegjqde

Confirmed Malicious Extensions

Sleeper Extensions

This post was originally published on the Socket blog.

Malware, Browser Extensions