GlassWorm Campaign Accelerates Malware Spread via 72 Malicious Open VSX Extensions

A significant malicious campaign associated with GlassWorm has intensified within the open VSX extensions ecosystem, revealing new methods for spreading malware through developer tools. Researchers have identified at least 72 additional malicious open VSX extensions since January 31, 2026, many of which serve as transitive loader extensions targeting developers.

This evolution of the GlassWorm campaign marks a shift from previous methods. Recent analyses indicate a strategic change in how the campaign disseminates malware, moving away from the direct embedding of malicious code in each extension. Instead, it now exploits the extension relationship mechanisms inherent in the Visual Studio Code ecosystem.

GlassWorm Exploits Extension Relationships

The campaign takes advantage of two specific manifest fields commonly utilized by open VSX extensions and compatible editors: extensionPack and extensionDependencies. These fields enable one extension to automatically install additional extensions when the primary extension is activated.

These settings are defined within an extension’s package.json file, referencing other extensions via the publisher.name identifier. In legitimate contexts, this functionality streamlines the developer experience, allowing for the bundling of multiple tools. For instance, a PHP development pack may include debugging and language tools, facilitating a smoother setup process.

However, GlassWorm operators have manipulated this feature to distribute malware indirectly through open VSX extensions.

Transitive Delivery Expands the GlassWorm Attack Surface

Unlike earlier iterations where malicious code was directly embedded, the newer GlassWorm strategy enables transitive malware delivery. A seemingly benign extension can be updated to include an extensionPack or extensionDependencies entry that installs a separate malicious extension.

One confirmed instance involves the extension otoboss.autoimport-extension, where version 1.5.7 includes a reference to oigotm.my-command-palette-extension, while version 1.5.6 links to federicanc.dotenv-syntax-highlighting, which has been confirmed as associated with GlassWorm.

Additional live cases have been identified, including:

• twilkbilk.color-highlight-css
• crotoapp.vscode-xml-extension

These examples demonstrate how open VSX extensions that initially appear harmless can later serve as indirect malware distribution points. This approach obscures the malicious components and complicates detection efforts.

The strategy undermines traditional extension review processes. Security teams can no longer rely solely on examining the initial release of an extension, as malicious dependencies may be introduced in subsequent updates.

Inflated Downloads and Impersonated Tools

Many of the malicious open VSX extensions linked to the GlassWorm campaign impersonate widely used developer tools to enhance their credibility. These include utilities such as linters, formatters, code runners, and language tools for frameworks like Angular, Flutter, Python, and Vue.

Other impersonated tools include:

• vscode-icons
• WakaTime
• Better Comments

The campaign also targets AI development tools, including extensions related to Claude Code, Codex, and Antigravity.

Some extensions have reported download counts in the thousands, likely manipulated by the threat actors to create an illusion of legitimacy. For instance, twilkbilk.color-highlight-css displayed 3.5K downloads while impersonating the legitimate color-highlight extension.

In another case, daeumer-web.es-linter-for-vs-code uses a publisher name that is a typosquat of the legitimate ESLint publisher dbaeumer.

As of March 13, 2026, the Open VSX registry has removed many of the transitively malicious extensions. However, some listings, including twilkbilk/color-highlight-css and crotoapp/vscode-xml-extension, remained active at the time of analysis, indicating ongoing takedown efforts.

GlassWorm Loader Evolution and Infrastructure Changes

While the distribution method has evolved, the underlying GlassWorm loader retains several recognizable characteristics. The latest variants continue to rely on:

• Staged JavaScript execution
• Russian locale and timezone geofencing
• Solana transaction memos used as dead drops
• In-memory follow-on code execution

Operational changes indicate efforts to enhance resilience and evade detection. For example, the campaign has rotated its Solana wallet infrastructure from:

• BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC

to:

• 6YGcuyFRJKZtcaYCCFba9fScNUvPkGXodXE1mJiSzqDJ

The operation has also introduced additional command-and-control IP addresses, including:

• 45.32.151.157
• 70.34.242.255

At the same time, it continues to reuse 45.32.150.251, suggesting continuity with earlier GlassWorm activity.

Other technical modifications include:

• Continued use of the Solana memo program MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr
• Replacement of the earlier static AES-wrapped loader with heavier RC4, base64, and string-array obfuscation
• Relocation of decryption keys from the extension code into HTTP response headers, specifically ivbase64 and secretkey

Security analysts have also highlighted embedded cryptographic indicators, such as:

• AES key: wDO6YyTm6DL0T0zJ0SXhUql5Mo0pdlSz
• AES IV: c4b9a3773e9dced6015a670855fd32b

As reported by thecyberexpress.com, the GlassWorm campaign represents a significant threat to developers and the broader software ecosystem, necessitating vigilance and proactive security measures.