GlassWorm Campaign 2025: How a VS Code Extension Worm Turned Stolen Developer Tokens Into New Infections

In October 2025, Koi Security reported GlassWorm, a malware campaign hidden inside extensions for Visual Studio Code and compatible editors on the Open VSX registry and Microsoft's VS Code Marketplace. The code was concealed using invisible Unicode characters, fetched its instructions from the Solana blockchain and Google Calendar, and went after the credentials developers use to publish software: npm, GitHub and Open VSX tokens. Koi called it self-propagating because those stolen tokens were used to push malicious updates to more extensions and packages. The Eclipse Foundation, which runs Open VSX, disputes the "worm" label, but agrees on the core point: publishing tokens were the fuel. The campaign has returned in several waves since.

At a glance

What happened

On 17 October 2025, versions 1.8.3 and 1.8.4 of the codejoy.codejoy-vscode-extension appeared on Open VSX with malicious code added. Koi Security's analysis, reported by BleepingComputer and SecurityWeek, found seven Open VSX extensions compromised at first, ten still serving malware a day later, and one on Microsoft's VS Code Marketplace by 19 October. BleepingComputer later put the total at 12 extensions.

The malicious code was hidden with invisible Unicode characters. Koi explained it this way: "To a developer doing code review, it looks like blank lines or whitespace. To static analysis tools scanning for suspicious code, it looks like nothing at all. But to the JavaScript interpreter? It's executable code." The loader looked up transactions on the Solana blockchain to find links to its next payload, with Google Calendar event titles as a backup channel and a direct IP address as a third option. Because blockchain records cannot be removed, Koi warned there was "literally no way to take it down."

Once running, GlassWorm collected npm, GitHub and Open VSX credentials, Git credentials, and data from 49 cryptocurrency wallet extensions. It also deployed a SOCKS proxy, hidden VNC remote access, and a module Koi called ZOMBI that turned infected machines into infrastructure for the attackers. Truesec summarised the propagation risk: "The stolen credentials are used to automatically compromise additional packages and extensions, creating exponential spread through the developer ecosystem."

The Eclipse Foundation's own account, published on 27 October 2025, gives a different view of how the attackers got in. It says Wiz had found "several extension publishing tokens inadvertently exposed by developers within public repositories", some for Open VSX accounts, and that GlassWorm "leveraged some of these leaked tokens to publish malicious extensions." It states that "This was not a self-replicating worm in the traditional sense" because the malware "did not autonomously propagate", although it stole credentials that "could then be used to extend the attacker's reach." It says all known malicious extensions were removed, the tokens involved were rotated or revoked, and it now considers the incident "fully contained and closed."

The campaign did not stop. In November 2025 BleepingComputer reported three new GlassWorm extensions on Open VSX. Koi, after gaining access to an attacker server through an anonymous tip, recovered data on 60 victims from a partial dataset, including "a government entity in the Middle East." In March 2026 Socket and Aikido reported 72 more malicious Open VSX extensions since 31 January 2026, which abused extension dependencies to pull in malware after install, alongside 151 affected GitHub repositories. In April 2026 Socket reported 73 "sleeper" extensions that looked harmless when first submitted and became malicious through later updates; six had been activated to deliver malware, with the other 67 assessed as dormant or suspicious.

Timeline

How it happened: the identity attack path

1. Publishing access. Attackers published malicious extension versions using valid publisher credentials. The Eclipse Foundation says these included publishing tokens that developers had leaked in public repositories.
2. Trusted distribution. Editors installed and updated the extensions from official marketplaces, so the code ran on developer machines with the developer's own access.
3. Credential harvesting. The payload collected npm, GitHub, Git and Open VSX credentials plus crypto wallet data.
4. Reuse of stolen publishing identities. Harvested tokens gave the attackers the ability to publish to more extensions and packages owned by victims, extending the campaign.
5. Resilient command and control. Instructions came from Solana transactions and Google Calendar events, which defenders cannot simply take offline.
6. Machines as infrastructure. SOCKS proxies and hidden VNC turned infected developer machines into assets for the attackers.

Impact

• Installs: about 35,800 installations according to Koi Security. The Eclipse Foundation says this "overstates the actual number of affected users" because of bot downloads.
• Credentials: npm, GitHub, Git and Open VSX credentials exposed on infected machines; tokens linked to the campaign rotated or revoked by Open VSX.
• Victims: Koi found 60 victims in a partial dataset, across the United States, South America, Europe and Asia, and a Middle East government entity.
• Persistence of the threat: repeated waves into 2026, with new techniques each time.
• Ecosystem changes: Open VSX committed to shorter token lifetimes by default, faster revocation and automated scanning at publication time.

What this means for NHI governance

GlassWorm sits at the point where developer secrets and software distribution meet. A publishing token for an extension or package is a non-human identity with enormous reach: whoever holds it can push code to every user of that extension. When those tokens are long-lived, stored on developer laptops and sometimes committed to public repositories, a single infection or leak can hand an attacker the means to reach thousands of machines.

The dispute over whether GlassWorm is a "worm" matters less than what both sides agree on. Tokens were leaked or stolen, then used to publish malicious code through trusted channels. Our earlier coverage of hard-coded secrets in VS Code extensions described Wiz's findings of more than 550 validated secrets across over 500 extensions. GlassWorm is what happens when that exposure is exploited.

The same pattern runs through the npm worms on our timeline, from Shai-Hulud to Miasma and Hades: steal the developer's publishing identity, then use it to spread.

Recommendations

• Shorten and scope publishing tokens. Use the shortest lifetime your registry allows and scope tokens to the specific extension or package. See Challenges of Rotating NHIs.
• Scan for leaked tokens. Run secret scanning on public and private repositories and extension bundles, and revoke anything found. The Secret Sprawl Challenge covers where these secrets hide.
• Control which extensions developers can install. Use an allow list for editor extensions and pin versions, so a malicious update is not installed automatically.
• Keep long-lived secrets off developer machines. Prefer short-lived, federated credentials for publishing from CI instead of personal tokens stored locally, as described in the NHI Authentication Guide.
• Respond to an infection as a credential incident. If an affected extension was installed, rotate npm, GitHub, Git, registry and cloud credentials that machine could reach, and review publishing activity on every package the developer owns.
• Assign owners to publishing identities. Track who holds each publishing token and review them regularly, following the NHI Lifecycle Management Guide.

Frequently asked questions

What is GlassWorm?

GlassWorm is a malware campaign found in October 2025 in extensions for VS Code and compatible editors on Open VSX and Microsoft's marketplace. It hides its code with invisible Unicode characters and steals developer credentials such as npm, GitHub and Open VSX tokens.

Is GlassWorm really a self-propagating worm?

Koi Security described it as self-propagating because stolen credentials were used to compromise more extensions and packages. The Eclipse Foundation says it was not a worm in the traditional sense because it did not spread autonomously, though the stolen credentials could extend the attacker's reach.

What should I do if I installed a GlassWorm extension?

Remove the extension and treat the machine as compromised. Rotate every token and credential it could access, including npm, GitHub, Git, registry and cloud credentials, and check any packages or extensions you publish for unexpected versions.

Related NHI Mgmt Group resources

Hard-coded secrets in VS Code extensions · Shai-Hulud npm campaign · JetBrains Marketplace malicious plugins · Miasma and Hades worms · The Secret Sprawl Challenge · NHI breaches

How NHI Mgmt Group can help

Securing Non-Human Identities (NHIs), including AI agents, is becoming increasingly crucial as attackers target publishing tokens, service accounts, API keys, tokens and secrets. Our NHI Foundation Level Training Course gives teams the practical grounding to find, govern and protect these identities.

References

• BleepingComputer: Self-spreading GlassWorm malware hits OpenVSX, VS Code registries (20 October 2025)
• SecurityWeek: Supply Chain Attack Targets VS Code Extensions With 'GlassWorm' Malware (21 October 2025)
• Truesec: GlassWorm, Self-Propagating VSCode Extension Worm (October 2025)
• Eclipse Foundation: Open VSX security update, October 2025 (27 October 2025)
• BleepingComputer: GlassWorm malware returns on OpenVSX with 3 new VSCode extensions (8 November 2025)
• The Hacker News: GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers (14 March 2026)
• BleepingComputer: GlassWorm malware attacks return via 73 OpenVSX "sleeper" extensions (27 April 2026)