GlassWorm VS Code Extension Worm Guide: How It Spreads and How to Stop It

GlassWorm turned code editor extensions into a credential theft channel: a developer installs or auto-updates an extension, and the extension quietly steals the GitHub, npm and Open VSX tokens that let the attacker publish the next malicious release. The campaign surfaced on the Open VSX registry in October 2025, reached the Visual Studio Code Marketplace, and returned in further waves into 2026. This guide profiles the malware, maps its behaviour to MITRE ATT&CK, explains why developer tokens are the fuel, and sets out detection, containment and extension governance controls. It is for security engineers, platform teams and developer experience owners who manage VS Code and its forks (Cursor, Windsurf, VSCodium and others that use Open VSX). For browser add-ons see the Browser Extension Security Guide; this page covers IDE extensions only.

Key takeaways

• The editor is a privileged runtime. VS Code extensions run with the user's full rights, so a malicious extension can read every token, SSH key and wallet on a developer workstation.
• Invisible code defeats review. GlassWorm hid its loader in Unicode variation selectors that render as blank space, so the malicious lines did not show up in editors or in diffs.
• Stolen publishing tokens drive the spread. Open VSX confirmed that tokens leaked by developers were used to publish malicious updates; each infection harvests more GitHub, npm and Open VSX credentials.
• Command and control is hard to take down. The malware read its next stage address from Solana blockchain transactions and kept a Google Calendar event as a fallback, so blocking one domain does not cut it off.
• Allowlisting is the control that works. VS Code 1.96 and later supports an AllowedExtensions policy; combined with token rotation and workstation monitoring it removes most of the exposure.

Who they are (names and aliases)

GlassWorm is the name Koi Security gave the malware and campaign; no public source has attributed it to a named threat group. MITRE ATT&CK tracks it as software S9010, recorded as spreading through VS Code extensions and GitHub JavaScript projects. The Eclipse Foundation, which runs Open VSX, disputes the "self-replicating worm" label in the traditional sense, because spread depended on stolen tokens and on operators publishing new versions rather than on automatic code propagation.

Targeting and motivation

• Who is hit: developers using VS Code compatible editors, particularly forks that pull from Open VSX by default. Victims are chosen by what they install, not by sector.
• What it wants first: developer credentials. Truesec reports theft of npm, GitHub and Git credentials; ATT&CK records collection of npm and GitHub authentication material from code repository tooling (T1213.003).
• What it wants next: money. Truesec lists 49 targeted cryptocurrency wallet browser extensions, and ATT&CK records tampering with hardware wallet desktop apps such as Ledger Live and Trezor Suite (T1565.002, T1554).
• What it builds: infrastructure. Infected machines can be turned into SOCKS proxies and given hidden VNC access, so a developer laptop becomes an access point and a relay.
• What it avoids: ATT&CK records that it checks the system language and skips Russian locale systems (T1614.001, T1480).

Tactics and techniques (MITRE ATT&CK)

Technique IDs are ATT&CK v20 relationships recorded against S9010, except T1176.002, which is the general technique for malicious IDE extensions and is included as a concept mapping.

Endor Labs found 6,492 invisible characters in one infected index.js and noted per operating system native decoder modules (.node files) and activation throttled to about once every two days through the extension's stored state. The point for defenders: static review by eye is not enough, and a single short sandbox run may miss the payload.

How they abuse identities and credentials

GlassWorm is an identity problem first and a malware problem second. The extension publishing model relies on personal access tokens, and those tokens leaked at scale before GlassWorm appeared. Wiz research published on 15 October 2025 found more than 550 validated secrets in more than 500 extensions, including more than 100 VS Code Marketplace publishing tokens and more than 30 Open VSX tokens; see the secrets in VS Code extensions breach analysis. Open VSX later confirmed that tokens leaked by developers in public repositories, not a compromise of its own platform, were used to publish GlassWorm releases.

Treat every token on an affected workstation as exposed. The developer's laptop is effectively a store of non-human identities: publishing tokens, cloud keys, API keys in .env files and agent configuration. The Developer Workstation and IDE Security Guide covers how to reduce what sits there.

Notable incidents

• October 2025, Open VSX and Marketplace: Truesec reported seven compromised Open VSX extensions on 17 October 2025, with ten still distributing malware two days later, and one extension on the VS Code Marketplace (cline-ai-main.cline-ai-agent version 3.1.3) on 19 October. Named Open VSX extensions included codejoy.codejoy-vscode-extension versions 1.8.3 and 1.8.4. The GlassWorm campaign breach page traces how stolen tokens became new infections.
• Registry response: the Eclipse Foundation said on 27 October 2025 that the incident was contained and closed on 21 October, the leaked tokens were revoked, and it was working on a recognisable token prefix with Microsoft's security response team, shorter token validity, faster revocation and automated scanning at publication. It also judged the widely reported figure of 35,800 downloads to be overstated.
• Later waves: secondary reporting summarised on the NHIMG breach page describes further Open VSX waves through to April 2026, including sleeper extensions that were published clean and turned malicious later. That pattern defeats one-time vetting.
• Related campaigns: the same token economy drives package worms. Compare the Shai-Hulud npm Worm Guide and the JetBrains Marketplace AI plugin campaign, which targeted AI API keys through IDE plugins.

Detection and defence

What to look for

• Extension inventory: collect installed extensions and versions from every developer host (for example with the VS Code command line option to list extensions with versions, or your endpoint management tool) and match against published GlassWorm indicator lists.
• Source and package scanning: flag files containing runs of Unicode variation selectors or private use characters, and eval of decoded strings. Endor Labs recommends editor formatting rules that reveal invisible characters plus automated Unicode anomaly checks.
• Network: editor or Node processes contacting Solana RPC endpoints, Google Calendar APIs or raw IP addresses, and peer to peer traffic (BitTorrent DHT, WebRTC) from developer machines.
• Endpoint: new HKCU or HKLM Run keys, new user LaunchAgents, hidden desktop sessions, and listening SOCKS proxies on workstations.
• Identity: GitHub audit log events for new tokens, unusual clone or push activity and new SSH keys; npm and registry publish events from unexpected locations. See the GitHub Audit Log Detection Guide.

Containment steps after a hit

1. Isolate the host and uninstall the extension; preserve the extension folder for analysis.
2. Revoke and reissue every credential the user could reach: GitHub, npm, Open VSX and Marketplace publishing tokens, cloud keys, SSH keys, API keys in local files, and browser sessions.
3. Check the user's publishing history on every registry for releases they did not make, and unpublish or deprecate them.
4. Look for wallet activity and hardware wallet app changes if wallets were present.
5. Reimage rather than clean, because the host may carry hidden VNC and proxy components. The Malicious Package Worm Response Playbook covers roles and evidence.

Prevention, in rollout order

1. Inventory first: gather a list of extensions in use and their publishers for two to four weeks before enforcing anything.
2. Allowlist in audit, then enforce: VS Code 1.96 and later supports the extensions.allowed setting and the AllowedExtensions policy (Group Policy, macOS configuration profile or Linux policy file). Allow by publisher or by specific extension and version, with "*": false to deny the rest. Microsoft documents that blocking an extension also disables installed copies, so pilot with one team and keep a quick rollback (remove or widen the policy).
3. Control the source: point forks at a curated registry where possible. Microsoft's private marketplace requires GitHub Enterprise; otherwise mirror an approved set.
4. Slow auto-update: Truesec advises caution with automatic updates, since malicious releases arrived as updates to trusted extensions. Pin versions for high-risk users such as release engineers.
5. Shrink the token footprint: move publishing to CI with short-lived credentials, scan extension packages for secrets before publishing, and keep wallets off development machines.

Decision guidance

• Publisher allowlist vs version pinning: publisher allowlists are easy to run but trust every future release; version pinning stops malicious updates but needs a review process. Use publisher allowlists for most staff and pinning for staff with publishing rights.
• VS Code vs forks: forks that rely on Open VSX may not honour Microsoft's policy settings in the same way; confirm the enforcement mechanism for each editor before relying on it.
• Small teams: a short allowlist and a monthly inventory check go a long way. Large estates need policy deployment through device management and an intake process with automated scanning.

Metrics

• Policy coverage: percentage of developer hosts with an enforced extension allowlist.
• Unknown extensions: count of installed extensions not on the allowlist (target: zero after enforcement).
• Token age: share of GitHub and registry tokens on developer hosts older than 30 days or without expiry.
• Rotation time: hours from a confirmed malicious extension to full credential rotation for affected users.
• Intake scanning: percentage of new extension versions scanned for invisible Unicode and secrets before approval.

Framework mapping

Practitioner checklist

• Pull an extension inventory from every developer host and compare it with GlassWorm indicators.
• Deploy the AllowedExtensions policy in a pilot, then enforce with "*": false.
• Pin extension versions for engineers who hold publishing rights.
• Scan repositories and extension packages for invisible Unicode and hard-coded tokens.
• Move extension, npm and GitHub publishing into CI with short-lived credentials and approval.
• Alert on Solana RPC, Google Calendar API and peer to peer traffic from editor processes.
• Monitor for new Run keys, LaunchAgents and hidden desktops on workstations.
• Keep a rotation runbook covering every credential type found on developer laptops.

Standards and references

• MITRE ATT&CK: GlassWorm (S9010)
• MITRE ATT&CK: Software Extensions: IDE Extensions (T1176.002)
• Eclipse Foundation: Open VSX Security Update, October 2025
• Microsoft Visual Studio Code: Manage Extensions in Enterprise Environments
• Truesec: GlassWorm Self-Propagating VS Code Extension
• Endor Labs: Invisible Threats, GlassWorm Unicode in VS Code Extensions
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Browser Extension Security Guide · AI IDE and Coding Agent Security Guide · Developer Workstation and IDE Security Guide · Shai-Hulud npm Worm Guide