GlassWorm Spreads via 72 Malicious Open VSX Extensions Hidden in Transitive Dependencies
The GlassWorm malware campaign has significantly advanced its approach in targeting software developers. The campaign now utilizes transitive dependencies to introduce malicious code into developer environments, rather than embedding malware directly…
The GlassWorm malware campaign has significantly advanced its approach in targeting software developers. The campaign now utilizes transitive dependencies to introduce malicious code into developer environments, rather than embedding malware directly into initial releases.
This method allows a seemingly secure package to incorporate an infected extension after trust has been established.
The Socket Research Team has identified at least 72 new malicious Open VSX extensions as of Tue, Jan 31, 2026.
VS Code and compatible editors, such as Open VSX, use manifest fields known as extensionPack and extensionDependencies to automatically install related tools alongside a main extension. GlassWorm exploits this convenience feature.
Initially, attackers publish a clean extension that passes basic security reviews. Later, an update introduces a malicious dependency. When the developer's editor updates the primary extension, the GlassWorm loader is silently installed in the background.
The GlassWorm malware campaign has significantly advanced its approach in targeting software developers.
For instance, researchers observed the package otoboss.autoimport-extension silently incorporating known malicious extensions like federicanc.dotenv-syntax-highlighting in subsequent versions. This tactic conceals the actual malicious component, indicating that a single extension review is insufficient for risk assessment.
The Socket Research Team notes that while the core GlassWorm techniques remain unchanged, the campaign has enhanced its evasion methods.
The malware continues to utilize staged JavaScript execution and Russian-language or time zone geofencing to bypass automated analysis. However, significant technical adaptations include:
Infrastructure Rotation: The attackers changed their Solana wallet and continue using Solana transaction memos as dead drops. Command and Control (C2): The campaign retains certain IP addresses while adding new ones. Advanced Obfuscation: The loader has shifted from using an AES-wrapped method to employing RC4, base64, and string-array obfuscation. External Decryption: Decryption keys are now retrieved from HTTP response headers rather than being stored directly within the extension.
The primary targets of this campaign are developer workstations. Attackers aim to extract local credentials, tokens, configuration data, and environment secrets directly from memory. Security measures should adapt to address these transitive attacks.
Audit Extension Histories: Conduct ongoing monitoring of version-to-version manifest changes to identify new extensionPack and extensionDependencies relationships. Review Install Chains: Examine the entire chain of extension updates rather than just the current top-level code. Monitor for Known Indicators: Identify GlassWorm markers such as staged loaders, Russian locale gating, and Solana memo lookups. Secure Endpoints: Regularly check developer workstations for exposed tokens or configuration files at risk if a follow-on payload executes. Leverage Security Tools: Use automated scanning solutions to flag suspicious dependency additions and block known malicious packages before integration into the environment.
Based on reporting by GBHackers.