GlassWorm Malware Exploits VS Code Extensions in Significant Supply Chain Attack

CyberSecureFox 🦊

Koi Security has documented a significant software supply chain attack in the Visual Studio Code ecosystem. A self-propagating malware dubbed GlassWorm was inserted into multiple extensions hosted on OpenVSX and the official Visual Studio Code Marketplace, leading to at least 35,800 installs. The campaign leveraged stolen developer credentials to ship trojanized updates, highlighting systemic risks in extension auto-update mechanisms.

Supply Chain Compromise of VS Code Extensions

GlassWorm spreads by abusing compromised publisher accounts to push malicious versions of legitimate extensions. The malware obscures its payload using invisible Unicode characters (such as zero-width characters), which complicates manual code reviews and automated scanning. Because VS Code extensions are configured to update silently in the background, users received the infected versions without prompts—turning routine updates into a covert infection vector.

Confirmed Compromised Extensions and Versions

According to Koi Security, at least 11 packages on OpenVSX and one on the Microsoft marketplace were affected:

At the time of Koi Security’s report, at least four malicious packages remained available on OpenVSX. Microsoft removed the affected extension from its marketplace, and the maintainers of vscode-theme-seti-folder and git-worktree-menu shipped cleansed updates.

How GlassWorm Works: Techniques, Payloads, and C2

Initial Access, Stealth, and Monetization

Post-installation, GlassWorm targets tokens and credentials for GitHub, npm, and OpenVSX to continue its lateral spread by publishing additional trojanized releases. It also seeks to exfiltrate data from cryptocurrency wallets supported by 49 VS Code extensions. For persistence and monetization, the malware deploys a SOCKS proxy and installs HVNC (hidden VNC), enabling covert remote access to the victim system.

The final-stage payload, labeled ZOMBI, is heavily obfuscated JavaScript that enlists compromised hosts into a botnet.

Multi-Channel Command-and-Control

GlassWorm uses a layered command-and-control (C2) architecture to improve resilience and evasion:

Primary: the Solana blockchain, where transaction data associated with an on-chain address embedded in the malware includes base64-encoded links to subsequent stages.

Fallback: Google Calendar, hiding base64 URLs within event titles.

Direct: connection to 217.69.3[.]218.

To further complicate takedowns and attribution, the campaign leverages the BitTorrent DHT for decentralized command distribution.

Risk Assessment and Indicators of Compromise

The core risk stems from publisher impersonation via stolen tokens and the silent auto-update workflow for extensions. Invisible Unicode obfuscation degrades static reviews, while compromised developer environments can cascade into CI/CD systems and code repositories. Even seemingly benign extensions (themes or utilities) can provide initial access for credential theft and botnet deployment.

Platform Response and Campaign Status

Microsoft responded by removing the malicious listing from the VS Code Marketplace. OpenVSX still contained several affected packages at the time of reporting. Some maintainers issued updates that removed the injected code. Organizations should monitor official advisories from Microsoft, OpenVSX/Eclipse Foundation, and the impacted publishers for ongoing remediation.

Recommended Actions for Developers and Security Teams

  • Inventory and audit: Check all installed extensions and versions against the list above. Remove or downgrade affected builds.
  • Credential hygiene: Revoke and rotate VS Code publisher tokens, GitHub and npm tokens. Enforce MFA/2FA and least-privilege scopes.
  • Hunt IOCs: Look for connections to 217.69.3[.]218, unusual Solana RPC traffic, suspicious Google Calendar API activity, unexpected SOCKS proxy services, or HVNC artifacts. Inspect extension folders for invisible Unicode and obfuscated JavaScript.
  • Update policy: Temporarily pause auto-updates for extensions or move to a staged allowlist model for enterprise fleets.
  • Supply chain hardening: Require verified publishers, cryptographic signing/provenance (e.g., Sigstore, SLSA), and SBOMs where possible.
  • Network controls: Apply egress filtering and DNS monitoring to flag anomalous destinations and decentralized overlays.
  • CI/CD isolation: Avoid using developer machines as build agents; segregate secrets and perform secret scanning across repos.

GlassWorm underscores that IDE extensions are part of the software supply chain and deserve the same rigor as any third-party dependency. Organizations should treat extension updates as code changes, implement strict publisher and version control, and proactively monitor for anomalous behaviors. Vigilant credential management and staged rollouts can significantly reduce exposure to similar campaigns.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.