Glitch in the Dev Stack: How GlassWorm Hijacked VS Code Extensions and Threatens the Entire Build Pipeline

In what security researchers are describing as a watershed moment for developer supply-chain attacks, a new malware campaign dubbed GlassWorm has begun spreading through extensions for Visual Studio Code (VS Code) and its open-source alternative, OpenVSX. The worm-like code has been installed on an estimated 35,800 developer machines so far.

What happened: A stealthy worm enters the IDE

According to analysts at Koi Security, the campaign first surfaced on October 17, 2025 when an extension named CodeJoy—published to OpenVSX—began exhibiting “suspicious behavioral changes.” Behind the façade of a routine plugin update, the malware used printable but invisible Unicode characters (specifically variation selectors) inserted into JavaScript files—so that to a human reviewer it looked like whitespace or blank lines, but to the interpreter the malicious code executed. “The malware is invisible,” wrote Koi’s CTO and co-founder, Idan Dardikman. “Not obfuscated. Not hidden in a minified file. Actually invisible to the human eye.”

From this pivot point, the worm evolved into a full-scale developer-environment compromise:

• It harvested credentials from npm, GitHub, Git, OpenVSX accounts.

• It targeted a range of cryptocurrency-wallet extensions (49-plus) to drain funds.

• It installed SOCKS proxy servers on infected machines, and hidden VNC clients, turning developer workstations into extended command-and-control (C2) infrastructure.

• It used the public Solana blockchain as a resilient C2 channel—transmitting base-64 encoded payload URLs via transactions—and even employed a backup C2 mechanism via a Google Calendar event. “You’re playing whack-a-mole with an opponent who has infinite moles,” Koi warned.

The campaign’s architecture is explicitly worm-like: stolen developer credentials are used to publish new malicious extensions or update existing ones—so each newly infected developer becomes a propagation node. “Each new victim becomes an infection vector … giving the malware its classification as a worm, and not a one-off infection,” Dardikman writes.

Why this should scare you

In past supply-chain attacks, adversaries compromised one library or binary and waited for downstream inclusion. GlassWorm shifts that paradigm: it actively spreads itself across developer environments and build pipelines. The insertion of invisible Unicode characters means traditional code-review tools and even human reviewers may see nothing amiss—even as executable malicious code sits inside.

“This marks the second incident in the past week that Microsoft’s OpenVSX has been targeted,” said Aditya Sood, VP of Security Engineering and AI Strategy at Aryaka. “There are two elements that make GlassWorm exceedingly difficult for security teams to handle. Firstly, the novel technique of utilizing invisible Unicode characters allows hackers to deploy payloads on blockchains while remaining nearly entirely hidden. Additionally, the malware uses the credentials it steals to automatically compromise more extensions, turning each new victim into an infection vector. This means that GlassWorm, if gone unchecked, can endlessly self-replicate itself and do so invisibly, leading to an uncontrollable spread through developer environments.”

That quote underscores the core risk: this isn’t just “one plugin got compromised,” this is developer machines themselves becoming part of the attacker’s infrastructure. The final stage module, dubbed ZOMBI, transforms each infected workstation into a node in a criminal proxy network.

The broader ecosystem impact

The fact that this is happening within IDE extensions raises the stakes considerably for organizations. Developer workstations often have high privileges, tokens, and direct access to build systems, internal code repositories, and artifact registries. If a developer machine becomes a SOCKS proxy or remote access endpoint under attacker control—everything downstream is suddenly compromised.

And it’s telling that the worm leveraged OpenVSX (an open-source marketplace) and infiltrated at least one extension on the official Microsoft VS Code marketplace—though Microsoft removed the extension swiftly once notified.

Mitigation: What should you do, now?

The researchers at Koi publish a set of indicators of compromise (IoCs) and recommended actions.

Key takeaways:

• Inventory your VS Code/OpenVSX extensions — Seek out unexpected or rarely-used extensions, especially themes or utilities from unfamiliar publishers.

  
  

• Disable auto-update for extensions (or set stricter policies) until you’ve assessed them, especially in enterprise contexts.

• Rotate all developer credentials and tokens — Everything from npm tokens to GitHub and Git credentials, and any machine-specific secrets.

• Assume compromised machines are already active infrastructure nodes — The guideline: “Format the machine to ensure full removal of the malware.”

• Treat developer environment hygiene as critical infrastructure — This means DevOps, engineering tooling, coding environments need same scrutiny as production servers.

What’s next?

We may just be witnessing the next stage of supply-chain attacks. The fact that malicious actors are using developer extensions as infection vectors, leveraging invisible code, and employing blockchain-based C2 channels indicates an advanced shift in tactics. Security teams and dev teams alike must treat the developer workstation as a first-class attack surface.

As Dardikman put it in his post:

“GlassWorm just proved that assumption wrong” — that human code review can reliably detect malicious changes.

If you’re involved in software development—especially in organizations where developers are entrusted with critical credentials or build access—this incident should serve as a wake-up call. The worm is out of the jar.