GlassWorm Supply Chain Attack Surges to 433 Compromised Components

The GlassWorm supply chain campaign has escalated dramatically, with security researchers now tracking 433 compromised components across the Open VSX registry, npm, and GitHub repositories as of March 18, 2026.

This represents a significant expansion from the 72 malicious VSCode extensions we reported last week, with threat actors deploying new evasion techniques and broader distribution channels.

What Changed This Week

Security teams at Aikido, Socket, Step Security, and the OpenSourceMalware community have collectively identified the expanded scope. The campaign now spans three major ecosystems that developers rely on daily.

On GitHub, compromises occurred between March 3-9, affecting at least 151 repositories. Notable targets include projects from Wasmer, Reworm, and opencode-bench from anomalyco—the organization behind OpenCode and SST. The attackers used stolen GitHub tokens to force-push malicious code into Python repositories.

The npm ecosystem saw two packages confirmed with the Unicode injection technique: @aifabrix/miso-client and @iflow-mcp/watercrawl-watercrawl-mcp. More are likely waiting to be discovered.

The Invisible Payload Technique

GlassWorm's signature method involves encoding malicious payloads inside invisible PUA Unicode characters in the ranges U+FE00-U+FE0F and U+E0100-U+E01EF. Every mainstream code editor, terminal, and code review interface renders these as nothing—making the injected code impossible to spot through visual inspection.

Once decoded, the payload passes to JavaScript's eval() function. The malware then deploys a multi-stage remote access trojan (RAT) that force-installs a malicious Chrome extension. This extension logs keystrokes, steals cookies, and exfiltrates data via Solana blockchain transactions used as a dead drop resolver for command-and-control servers.

The Solana-based C2 approach allows attackers to rotate infrastructure without hardcoding traditional server addresses, complicating blocklist-based defenses.

New Transitive Delivery Method

The March wave introduced a more insidious technique. Instead of embedding the loader directly in every malicious listing, attackers now abuse the extensionPack and extensionDependencies fields in Open VSX extensions.

Socket researchers noted that this allows threat actors to "establish trust through a seemingly legitimate extension, then deploy malware through dependencies after the initial package gains adoption." Extensions receive updates with heavier obfuscation and rotating Solana wallets, while mimicking legitimate developer tools like linters, formatters, and AI coding assistants.

LLM-Generated Cover Commits

The campaign employs AI-generated commit messages to blend in—documentation tweaks, version bumps, and small refactors that look routine. One repository showed 47 commits over three days, all appearing as normal maintenance activity while incrementally introducing the malicious Unicode payload.

Targeting Non-Russian Systems

Researchers observed the malware checking system locale settings and avoiding infection on machines configured for Russian locales. This targeting pattern aligns with previous supply chain campaigns attributed to Eastern European actors operating outside their home region.

Detection and Response

Step Security advises developers who install Python packages directly from GitHub or run cloned repositories to check for signs of compromise:

1. Search your codebase for the marker variable lzcdrtfxyqiplpd—this is a known GlassWorm indicator
2. Review any Chrome extensions installed in the past 30 days
3. Audit GitHub Actions workflows for unexpected token usage
4. Check for Solana wallet addresses in network traffic logs

For organizations using Open VSX, Socket recommends reviewing extension installation dates against the March 3-14 window and examining any extensions with recent dependency changes.

Why This Matters

Developer tooling has become prime real estate for supply chain attacks. The shift from traditional package manager compromises to IDE extensions represents an escalation—code review and security scanning typically focus on runtime dependencies, not development environment components.

The 433-component scope here dwarfs previous campaigns. And because IDE extensions often have broad filesystem and network permissions, a single compromised extension can provide persistent access that survives system reboots and credential rotations.

Security teams should treat developer workstations as high-value targets requiring the same scrutiny as production servers. The days of assuming local development environments are isolated from enterprise risk are over.