The malware you approved because you couldn’t see it

Your reviewer read the pull request. Every line rendered clean: a version bump, a small refactor, a doc tweak. Nothing looked wrong, because the part that was wrong was never drawn on the screen. It was written in Unicode characters that carry no glyph. Invisible to your eyes, invisible to the diff view, invisible to the human sign-off that supply-chain security still leans on.

That is GlassWorm. Since October, researchers at Koi Security have tracked the first self-propagating worm to spread through VS Code extensions, and it has not stopped [1]. Socket flagged more than seventy fresh malicious extensions on the Open VSX marketplace since the end of January [2]. The loader hides inside invisible Unicode, so the code sails through review looking like housekeeping.

What it does after it installs is the ordinary part, and that is the point. It reads what is lying around. npm tokens. GitHub credentials. the Git config. environment variables and CI secrets sitting open in your workspace. Then it uses those stolen credentials to publish more poisoned packages under your name, which is how a worm becomes a worm. Command and control rides Solana transactions, so there is no server to seize [3].

Here is the reframe. Nobody hacked @code. Open VSX was not breached in the classic sense. The extension model did exactly what it was designed to do: you install a helper, and it runs with your permissions, inside your open project, next to your secrets. That model was built for a world where the extension author was the only party you had to trust. GlassWorm turns a trusted author’s account into a delivery truck and hides the cargo in characters you cannot see. The tool did not fail. The threat model moved under everyone at once.

Which lands on an uncomfortable question about your own machine. When an extension you trusted opens your project, what is there for it to take?

For most developers the answer is: everything. A long-lived npm token in a dotfile. A personal access token that a helpful setup guide told you to paste once and forget. Secrets in an env file that every process on the box can read. These credentials sit at rest, in the exact place the code runs, waiting for anything with local access. An invisible worm in your editor does not need to break encryption. It needs a file.

Clavitor starts from the opposite assumption. A credential is brokered at the moment it is needed, scoped to the one thing it is for, and it expires. It is never written into your dev environment to be discovered later. So when hostile code sweeps the workspace for keys at rest, there is no standing npm token, no forever GitHub PAT, nothing that outlives the second it was used. The worm opens the drawer, and the drawer is empty.

The honest edge: a credential in active use is still live while it is in use. If your session is running and hostile code shares that session, it can ride what is live right then, inside that credential’s short window and narrow scope. Ephemeral, scoped issuance shrinks the blast radius and the clock. It does not make a machine you have handed to an attacker safe. Nothing does. But there is a wide gap between an attacker who catches one scoped credential mid-use and an attacker who copies a file of permanent keys and owns you for a year.

We wrote up the short list of things a credential system should never do. Near the top: don’t leave secrets sitting where the code runs. Read them here

Clavitor (@clavitorai) is the credential vault built for AI agents, and against them. clavitor.ai

Sources

[1] Koi Security — "GlassWorm: The First Self-Propagating Worm Using Invisible Code Hits the Open VSX Marketplace" (research firm; no verified X handle)

[2] Socket, via @TheHackersNews — "GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers" (@SocketSecurity)

[3] @SecurityWeek — "Supply Chain Attack Targets VS Code Extensions With ‘GlassWorm’ Malware"