News · Security · November 12, 2026

Breach Briefing: the npm worm that read developer secrets

ChainDrop spread through more than 400 npm packages and took tokens and keys from laptops and CI. What it stole, and where your secrets should not live.

DRIVE 369 DAO · 2 min read

A Breach Briefing: one real incident, with sources, and the habit it teaches.

What happened

On August 4, 2026, Microsoft published an analysis of ChainDrop, a self-spreading worm in the npm package registry (Microsoft Security blog). It affected more than 400 packages from unrelated publishers. Microsoft's evidence points to a stolen maintainer credential for the first compromise. After that, stolen publishing tokens did the rest: each infected package carried a script that ran on install, fetched the latest version of every package that publisher controlled, added itself and published again. Singapore's cyber agency issued an advisory on the same campaign (CSA).

What it took

The worm searched for npm, GitHub, cloud and infrastructure credentials in local files, shell histories, cloud configuration, SSH keys, environment variables and the memory of build runners, then used them against npm, GitHub, AWS, Kubernetes and HashiCorp Vault. It also wrote Claude and VS Code configuration files into repositories, so the next developer who opened the project could be infected. Because some releases went through a legitimate build workflow, they carried valid provenance, so a green check did not mean safe.

The lesson

An attacker who runs code on your machine reads whatever is lying around. Secrets in plain files and environment variables are the loot. The same is true of the key to your cloud account, your server, or your AI provider.

What helps

• Keep secrets out of dotfiles and shell history. Store API keys and SSH keys in a manager, one sealed item each, and paste them when needed. In Ghostdrive's Pass, every item has its own key and the clipboard is cleared after 30 seconds.
• Do not install the newest version the minute it appears. Microsoft recommends pinning known-good versions and using a minimum release age.
• Rotate from a clean machine if a bad version ever ran.
• Give tokens narrow scopes and short lives. One stolen token should reach one thing.

What we do ourselves

Ghostdrive is built with npm, so we are not outside this story. Our guards are narrow and checkable: the private AI model's files are checked against their pinned hashes every time they load, the desktop app sends its node token only to a listener that proved it knows the token, and an installer is never trusted because it is on a page we control. These are some of the fixes from our own scan.

Use case: a solo developer

You keep a cloud key in an environment file and an SSH key in your home folder. Move both into sealed items, load them per session, and delete the files. If a poisoned package runs on your laptop tomorrow, there is much less lying around for it to read.

Academy: start here · Pass · Security and audits