GlassWorm Supply-Chain Attack Hits 72 Open VSX Extensions, 151 GitHub Repos, and npm in Coordinated Developer Assault

RedSheep Reports | March 16, 2026

The GlassWorm campaign has scaled into a multi-platform assault on developer infrastructure. Socket's research team reported 72 new malicious extensions on the Open VSX Registry on March 13, 2026 [2]. Between March 3 and March 9, Aikido documented 151 compromised GitHub repositories [4]. Two malicious npm packages using the same tradecraft surfaced in parallel, confirming a coordinated push across at least three ecosystems simultaneously [1]. This isn't a single poisoned package. It's a self-propagating worm with an expanding attack surface.

The campaign's evolution is notable. When Koi Security first flagged GlassWorm on October 18, 2025, it centered on a single extension called CodeJoy with 35,800 active installations [6]. Six months later, the threat actor has shifted from direct malware embedding to abusing transitive dependencies, deployed invisible Unicode characters to hide payloads in plain sight, and built command-and-control infrastructure on the Solana blockchain. This is a sustained, iterative operation by a capable actor.

Background: GlassWorm's Origins and Trajectory

GlassWorm first appeared when Koi Security researchers discovered the CodeJoy extension on OpenVSX was delivering malicious payloads to developer machines [6]. That initial variant targeted 49 different cryptocurrency wallet extensions and deployed both a SOCKS proxy and Hidden VNC (HVNC) module for remote access [6]. The malware used invisible Unicode characters and BitTorrent DHT for decentralized command routing [6].

The January 2026 wave marked the first major escalation. On January 30, four extensions published under the developer account "oorzc" were compromised, collectively accounting for over 22,000 downloads [5]. The affected extensions (FTP/SFTP/SSH Sync Tool, I18n Tools, vscode mindmap, and scss to css) were legitimate tools whose publishing credentials had been leaked [5]. Socket's analysis determined the attacker used a stolen token to push malicious versions that included staged loaders with Russian-locale avoidance [5].

Since January 31, Socket has identified 72 additional malicious Open VSX extensions, bringing the total campaign footprint well beyond the initial compromise [1]. The majority of these extensions were removed from Open VSX as of March 13, 2026 [3].

Technical Detail: Transitive Dependency Abuse

The most significant tactical shift in the March wave is GlassWorm's move from embedding loaders directly in each malicious extension to abusing the extensionPack and extensionDependencies fields in VS Code extension manifests [1][2][3]. This is a transitive delivery mechanism. A seemingly benign extension declares a dependency on a second extension that contains the actual payload. The user installs the first; VS Code silently pulls in the second.

Socket described this shift directly: "Instead of requiring every malicious listing to embed the loader directly, the threat actor is now abusing extensionPack and extensionDependencies" [1]. This approach has real advantages for the attacker. It reduces the number of extensions that need to contain overtly malicious code, making detection harder. It also means a single payload extension can serve as the backend for multiple front-facing impersonator packages.

Examples of this pattern include otoboss.autoimport-extension and twilkbilk.color-highlight-css, the latter showing inflated download counts of 3,500 [3].

Technical Detail: Impersonation Targets

The 72 extensions impersonate widely-used developer tools. The campaign mimics AI-powered coding assistants like Claude Code and Google Antigravity, as well as staples like ESLint, Prettier, Python language support, Vue, Angular, and Flutter tooling [1][2]. The extension aadarkcode.one-dark-material@3.20.1 represents one of the more recent variants identified [3].

This selection is strategic. AI coding assistants are new enough that developers may not have strong expectations about legitimate publisher identities. Traditional tools like ESLint and Prettier have massive user bases, making typosquatting viable at scale.

Technical Detail: Payload Delivery and Execution

The core execution chain has remained consistent across GlassWorm variants. The malware uses staged JavaScript execution with in-memory follow-on code [2][3]. Remote decryption keys are retrieved from attacker-controlled HTTP endpoints via custom response headers named ivbase64 and secretkey [2]. This means the encrypted payload ships with the extension, but it can't execute without phoning home for the keys.

The campaign uses Solana blockchain transaction memos as dead drops for C2 rotation [2][5]. This is a resilience mechanism. Traditional domain-based C2 can be taken down through registrar action. Blockchain transaction data is immutable and publicly readable, making it effectively impossible to disrupt without compromising the attacker's wallet keys.

The malware implements Russian locale and timezone geofencing, deliberately avoiding execution on systems configured for Russian locales [2][5]. This is a common pattern in Eastern European cybercrime operations, typically interpreted as a protective measure to avoid drawing attention from domestic law enforcement.

Technical Detail: Invisible Unicode in GitHub and npm

The GitHub and npm components of the campaign use a different concealment technique. Aikido found that 151 repositories were compromised between March 3 and 9 with injections using Unicode Private Use Area characters in the ranges 0xFE00-0xFE0F and 0xE0100-0xE01EF [4]. These characters are invisible in most code editors and review interfaces, making the malicious modifications extremely difficult to spot during code review.

Notable targets included repositories associated with Wasmer, Reworm, and anomalyco [4]. Aikido assessed that the attackers are likely using LLMs to generate contextually appropriate cover changes for their commits, noting that "the malicious injections don't arrive in obviously suspicious commits" [4].

Two npm packages, @aifabrix/miso-client and @iflow-mcp/watercrawl-watercrawl-mcp, used the same invisible Unicode technique, confirming the cross-platform coordination [4][1].

IOC Table

MITRE ATT&CK Mapping

Detection and Hunting

Extension Manifest Analysis: Defenders should audit VS Code and Open VSX extension manifests for suspicious extensionPack and extensionDependencies entries. Extensions that declare dependencies on obscure or recently-published packages warrant investigation. Pull the package.json from installed extensions and cross-reference dependency publisher accounts against known-good lists.

Network Indicators: Monitor for outbound connections to 45.32.151.157, 70.34.242.255, and 217.69.3.218 [2][6]. HTTP response headers containing ivbase64 and secretkey fields are strong indicators of GlassWorm key retrieval [2]. A SIEM query like http.response.header.name:(ivbase64 OR secretkey) on proxy or NDR logs will catch this.

Solana RPC Traffic: GlassWorm's use of Solana transaction memos for C2 means defenders should watch for unexpected connections to Solana RPC endpoints (commonly api.mainnet-beta.solana.com or third-party providers like Alchemy/Helius). Developer workstations have no legitimate reason to query blockchain RPCs unless the developer works on Web3 projects.

Unicode Anomaly Detection: For the GitHub and npm vector, scan repositories for Unicode characters in the Private Use Area ranges 0xFE00-0xFE0F and 0xE0100-0xE01EF within JavaScript or TypeScript files [4]. A simple grep: grep -rP '[\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]' ./src/ will surface invisible character injections.

Behavioral Signals: Extensions that execute immediately on install, make outbound HTTP requests during activation, or read cryptocurrency wallet extension storage directories are high-priority for investigation. Monitor process creation from VS Code extension host processes, particularly node child processes spawning network connections.

Analysis

GlassWorm represents a qualitative step forward in supply chain attacks on developer tooling. The shift to transitive dependency abuse through extensionPack and extensionDependencies is a direct adaptation to improved detection of directly-embedded payloads. Socket's earlier work on the January compromises likely forced the actor to change tactics, and they responded within weeks [1][3].

The simultaneous targeting of Open VSX, GitHub, and npm indicates an actor with sufficient operational capacity to maintain multiple concurrent campaigns. The use of LLM-generated cover commits for GitHub injections [4] suggests the actor is investing in automation to scale their operations while maintaining plausibility.

The Solana-based C2 mechanism is particularly concerning from a defensive standpoint. Traditional takedown procedures don't work against blockchain infrastructure. The C2 channel will remain functional as long as the attacker can write transaction memos to their wallet, which costs fractions of a cent per message.

The Russian-locale avoidance is consistent with a threat actor operating from Russia or a CIS country. Combined with the financial targeting (49 cryptocurrency wallet extensions) [6], this looks like a financially-motivated operation rather than state-sponsored espionage, though the infrastructure sophistication exceeds typical cybercrime.

References

1. The Hacker News: GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers
2. CybersecurityNews: GlassWorm Campaign Uses 72 Malicious Open VSX Extensions to Broaden Reach
3. Socket: 72 Malicious Open VSX Extensions Linked to GlassWorm Campaign
4. Aikido: Glassworm Returns: Invisible Unicode Malware Found in 150+ GitHub Repositories
5. Socket: GlassWorm Loader Hits Open VSX via Developer Account Compromise
6. BleepingComputer: Self-spreading GlassWorm malware hits OpenVSX, VS Code registries