A large-scale malicious campaign tied to GlassWorm has expanded within the ecosystem of open VSX extensions, introducing a method of spreading malware through developer tools. Researchers identified at least 72 additional malicious open VSX extensions beginning January 31, 2026, including several that function as transitive GlassWorm loader extensions aimed at developers. 

Rather than reappearing as a completely new operation, GlassWorm has evolved its tactics. Recent analysis shows a notable escalation in how the campaign spreads through open VSX extensions, shifting from directly embedding malicious code into every extension to exploiting the extension relationship mechanisms within the Visual Studio Code ecosystem. 

GlassWorm Exploits Extension Relationships

The campaign abuses two extension manifest fields commonly used by open VSX extensions and compatible editors: extensionPack and extensionDependencies. These fields allow one extension to automatically install additional extensions when the primary extension is installed. 

Both settings are declared inside an extension’s package.json file and reference other extensions using the publisher.name identifier. In legitimate scenarios, this functionality provides convenience for developers. For example, extension packs can bundle multiple tools together so that a developer setting up a particular environment can install them all at once. 

A legitimate example cited in official documentation shows how a PHP development pack might bundle debugging and language tooling: 

{
 “extensionPack”: [“xdebug.php-debug”, “zobo.php-intellisense”]
} 

However, GlassWorm operators have repurposed this functionality to distribute malware indirectly through open VSX extensions. 

Because these manifest fields do not require extensions to share the same publisher or namespace, any extension author can reference any other extension. This design allows attackers to publish seemingly harmless extensions that later become indirect malware installers. 

Transitive Delivery Expands the GlassWorm Attack Surface 

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

One confirmed example involves otoboss.autoimport-extension, where version 1.5.7 includes an extensionPack reference to oigotm.my-command-palette-extension, while version 1.5.6 references federicanc.dotenv-syntax-highlighting, which has been confirmed as GlassWorm-linked. 

Additional live cases were also identified, including: 

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

These examples illustrate how open VSX extensions that initially appear harmless can later become indirect malware distribution points. This approach reduces visibility of the malicious component and complicates detection efforts. 

The strategy also undermines traditional extension reviews. Security teams can no longer rely on examining only the initial release of an extension, since malicious dependencies may be introduced in later updates. 

Inflated Downloads and Impersonated Tools 

Many of the malicious open VSX extensions in the GlassWorm campaign impersonate widely used developer tools to increase credibility. These include utilities such as linters, formatters, code runners, and language tools for frameworks, including 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 showed download counts in the thousands, likely manipulated by the threat actor to make the packages appear legitimate. One example, twilkbilk.color-highlight-css, displayed 3.5K reported 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 removed many of the transitively malicious extensions. However, some listings, including twilkbilk/color-highlight-css and crotoapp/vscode-xml-extension, were still active at the time of analysis, indicating that takedown efforts were ongoing. 

GlassWorm Loader Evolution and Infrastructure Changes 

While the distribution method has evolved, the underlying GlassWorm loader retains several recognizable characteristics. 

The latest variants still rely on: 

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

However, several operational changes indicate an effort to improve resilience and evade detection. 

For example, the campaign rotated Solana wallet infrastructure from: 

• BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC 

to 

• 6YGcuyFRJKZtcaYCCFba9fScNUvPkGXodXE1mJiSzqDJ 

The operation 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 also highlighted embedded cryptographic indicators, such as: 

• AES key: wDO6YyTm6DL0T0zJ0SXhUql5Mo0pdlSz
• AES IV: c4b9a3773e9dced6015a670855fd32b