Skip to content
Now taking design partners.Roadmap →

vs code + openvsx · 2025

GlassWorm

Self-propagating worm across the VS Code Marketplace and OpenVSX extension registries. Koi Security disclosed on October 18 2025. Signature traits are invisible-Unicode obfuscation and Solana blockchain C2.

Run this campaignScale: 35,800 installs, self-propagating VS Code + OpenVSX worm

What happened

On October 18 2025, researchers at Koi Security (Idan Dardikman) disclosed a self-propagating worm active across both the OpenVSX registry and the VS Code Marketplace. Those are the two extension homes for VS Code and its forks (Cursor, Windsurf, VSCodium). The worm was dubbed GlassWorm, and the combined install count across affected extensions reached roughly 35,800 before takedowns started. Aikido published follow-on analysis after Koi's initial disclosure.

Unlike a one-off malicious extension, GlassWorm chained account takeovers to push updates through the auto-update channel of legitimate publishers, converting installs into further compromise vectors.

Signature traits

GlassWorm's fingerprint is a pair of techniques rarely seen together in extension malware:

  • Invisible-Unicode obfuscation. The payload lives in Unicode Tags Block characters (U+E0000–U+E007F). Codepoints that render as zero-width but are still parsed by JavaScript. A source-diff review of the extension looks clean; the malicious code is literally invisible in every editor and every code-review UI. Static scanners that don't strip Tags Block characters before analysis see benign source.
  • Solana blockchain C2. Rather than hard-coding a C2 endpoint, the worm reads its C2 address from a Solana smart contract. Blockchain reads are censorship-resistant name resolution. Takedowns of individual C2 domains do not sever the channel because the address can be rotated on-chain and every infected extension picks up the new endpoint on next fetch.

How it propagated

The worm operated in two stages. Stage one: credential theft on the developer box that installed the initial malicious extension. VS Code personal access tokens for the marketplace, OpenVSX publisher credentials, git tokens. Stage two: use those tokens to publish tainted updates of any extension the compromised publisher owned. Because both marketplaces auto-update by default, existing installs across the fleet were pulled into the tainted version without user action.

What Drig sees

The ide_ext collector walks VS Code's extension directory (~/.vscode/extensions, ~/.vscode-server/extensions on Linux/macOS; the equivalent under %USERPROFILE%\.vscode on Windows) and OpenVSX-derived paths for VSCodium and forks. It streams extension ID, publisher, and version. The signed catalog carries the flagged extension IDs and version ranges; retro-match surfaces exposed developer machines in the console, listed by extension and publisher.

Rotation checklist

  • Force-uninstall flagged extension IDs across enrolled endpoints.
  • Revoke publisher tokens for VS Code Marketplace and OpenVSX on any account that installed the malicious extension.
  • Rotate git tokens, npm tokens, and GitHub PATs on developer machines that ran the tainted extension.
  • Clear the extension's storage directory to remove any staged payloads.
  • Force IdP re-auth for the developer identities involved.

Marketplace-scale worms are exactly the class of incident a scheduled-scan inventory model handles cleanly: catalog updates, retro-match runs, exposed hosts appear. No agent release required.