The GlassWorm malware campaign has evolved, significantly escalating its attacks on software developers.
Instead of embedding malware directly into initial releases, the threat actors are now using transitive dependencies to sneak malicious code into developer environments.
This stealthy approach allows a seemingly safe package to pull in a separate, infected extension only after establishing trust.
According to a recent report by the Socket Research Team, at least 72 new malicious Open VSX extensions have been identified since January 31, 2026.
The Transitive Delivery Mechanism
VS Code and compatible editors, such as Open VSX, use manifest fields called extensionPack and extensionDependencies to install related tools alongside a main extension automatically. GlassWorm actively abuses this convenience feature.
Attackers initially publish a clean, standalone extension that easily passes basic security reviews.
twilkbilk.color-highlight-css Open VSX extension (Source: Socket)Later, they release an update that adds a malicious dependency. When the developer’s editor updates the primary extension, it silently installs the GlassWorm loader in the background.
For example, researchers observed the package otoboss. autoimport-extension quietly pulling in known malicious extensions like federicanc. dotenv-syntax-highlighting in later versions.
This tactic hides the true malicious component and proves that a one-time review of an extension is no longer sufficient for risk assessment.
The Socket Research Team notes that while the core GlassWorm tradecraft remains intact, the campaign has rapidly improved its evasion techniques.
The malware still relies on staged JavaScript execution and Russian-language or time zone geofencing to evade automated analysis. However, several key technical shifts have occurred:
- Infrastructure Rotation: The attackers shifted their Solana wallet from BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC to 6YGcuyFRJKZtcaYCCFba9fScNUvPkGXodXE1mJiSzqDJ. They continue to use Solana transaction memos as dead drops.
- Command and Control (C2): The campaign continues to reuse IP address 45[.]32[.]150[.]251 while adding new IPs like 45[.]32[.]151[.]157 and 70[.]34[.]242[.]255.
- Advanced Obfuscation: The loader moved from a static AES-wrapped method to heavier RC4, base64, and string-array obfuscation. Embedded crypto indicators still include AES key wDO6YyTm6DL0T0zJ0SXhUql5Mo0pdlSz and IV c4b9a3773e9dced6015a670855fd32b.
- External Decryption: Decryption keys are no longer stored directly inside the extension. They are now retrieved from HTTP response headers, such as ivbase64 and secretkey.
Mitigation and Defense Strategies
The ultimate targets of this campaign are developer workstations, with attackers aiming to steal local credentials, tokens, configuration data, and environment secrets directly from memory. Security teams must adapt their defenses to catch these delayed, transitive attacks.
- Audit Extension Histories: Do not rely solely on the initial code review. Monitor version-to-version manifest changes for newly introduced extensionPack and extensionDependencies relationships.
- Review Install Chains: Examine the entire chain of extension updates rather than just the current, top-level code of the tool you installed.
- Monitor for Known Indicators: Hunt for 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 that might be accessible if a follow-on payload executes.
- Leverage Security Tools: Utilize automated scanning solutions to flag suspicious dependency additions and block known malicious packages before they are fetched into the environment.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
