Signed, Provenanced and Malicious: What the 2026 npm Worms Teach About Your Install Pipeline

What Happened With ChainDrop, and Why Is It Still Spreading?

On 4 August 2026, attackers compromised the GitHub account of the maintainer behind keyv, a family of caching utilities that sits deep inside a large share of the JavaScript ecosystem. According to Aikido's incident write-up, the attackers pushed malicious files straight to the main branch and immediately cut new releases, and by the following day at least 444 packages across 1,381 versions had been compromised. Singapore's Cyber Security Agency put the scale in plainer terms in its 6 August advisory: over 1,300 npm package versions, representing about 2 billion monthly downloads.

The malware, which researchers named ChainDrop, is the latest descendant of the Shai-Hulud worm that first hit npm in September 2025, when GitHub says it removed more than 500 compromised packages from the registry. The mechanics will be familiar to anyone who followed that first wave. Each poisoned package gained a preinstall hook that runs a dropper, setup.mjs, which downloads the Bun runtime and executes an obfuscated credential stealer. Elastic Security Labs found that the collector scans over 300 unique patterns, covering cloud credentials for AWS, GCP and Azure, GitHub tokens, SSH keys, Kubernetes service account tokens, Vault tokens and npm tokens.

What makes it a worm rather than a single compromise is what it does with those tokens. Elastic's analysis describes how, for every package a stolen npm token can write to, the payload downloads the latest tarball, injects itself, bumps the patch version and republishes. Each infected maintainer becomes the next distribution point. The affected packages were not obscure: Elastic counted over 600 million downloads in the previous month for keyv alone and close to 580 million for flat-cache, and BleepingComputer reported infected packages tied to Deliveroo, Picsart, Qlik and ServiceTitan.

The campaign did not end in August. On 8 October, The Hacker News reported that version 0.5.144 of the tensorlake TypeScript SDK had been published with the same ChainDrop payload after a rogue commit on 7 October. This variant added a nasty twist: a monitor that checks whether the stolen GitHub token is still valid and, if it has been revoked, runs a handler designed to wipe the victim's home directory. Two months after the first alert, the worm is still finding new maintainers to ride.

Why Didn't Provenance Stop It?

For the last two years the industry's answer to package tampering has been provenance: cryptographic attestations that link a published package to the source repository and CI workflow that built it. GitHub, npm and most security vendors have pushed teams to prefer packages with provenance and publishers to adopt trusted publishing. That advice is still correct. ChainDrop simply showed its limits with unusual clarity.

Because the attackers pushed their code into the real repository and let the real release pipeline build it, the poisoned versions were, as Aikido put it, published to npm with valid provenance signed by GitHub Actions. BleepingComputer made the same point: because the releases were built through legitimate workflows, they carried valid provenance information. Every check that asks "was this built where it claims to be built?" passed, because it was.

The same logic undermines the assumption that moving to OIDC-based trusted publishing makes a pipeline safe on its own. Aikido found that on GitHub Actions runners the payload reads runner process memory and steals the OIDC tokens used for npm publishing. Short-lived credentials shrink the window an attacker has, but a worm that executes inside the job does not need a long window. It needs one install.

None of this means provenance is useless. It still makes it much harder to publish a package from an attacker's laptop and pass it off as the real thing, and it gives responders a precise trail back to the commit that introduced the malware. The lesson is narrower and more important: provenance answers where a package came from, not whether you should run it. Your controls have to address the second question too.

Why Are AI Coding Tools Now Part of the Attack Surface?

The most significant change in this wave is where the worm chose to persist. When it obtains a GitHub token, Elastic found that it commits a SessionStart hook into .claude/settings.json and a folderOpen task into .vscode/tasks.json, across up to 50 branches per accessible repository. The result is that a developer does not need to install anything to be infected. Opening the repository in VS Code, or starting a Claude Code session in it, runs the payload.

The disguise is deliberately mundane. Elastic notes that the worm's commits are authored as claude with the message chore: update config. In a team where coding agents already open pull requests and touch configuration files every day, a commit like that looks like routine automation. It is exactly the kind of change a tired reviewer approves without expanding the diff.

The worm is also hunting for AI credentials specifically. Elastic lists Anthropic, Claude, Codex, Cursor, OpenAI and Gemini credentials among its targets, and the October Tensorlake variant, according to The Hacker News, went after configuration files for Claude, Cursor, Kiro, Windsurf and Zed. API keys for model providers are valuable on their own, and an agent configuration often reveals which internal tools and MCP servers a developer can reach.

This is the practical meaning of a trend we have written about before. In our piece on attacks against coding agents, the threat was untrusted content steering an agent. ChainDrop is the mirror image: the agent's own configuration becomes the persistence mechanism. Any file that a tool executes automatically when a project opens, whether editor tasks, agent hooks, devcontainer scripts or git hooks, is code. It deserves the same review, ownership and protection as anything in src/.

Is This a One-Off or the New Baseline?

The numbers say baseline. Sonatype's Q1 2026 Open Source Malware Index identified 21,764 malicious open source packages in the first quarter alone, bringing its total since 2017 to 1,346,867, with npm accounting for 75% of new malicious packages. Its Q2 index put the running total at more than 1.8 million and found npm accounted for 96.6% of packages in the quarter.

The character of the attacks matters more than the count. Sonatype's Q1 headline was that trust abuse had become the most successful attack vector, and its CTO Brian Fox summarised attackers' success as having "abused trust already built into the software lifecycle." The Q2 report observed that modern open source malware often executes during installation, build or CI/CD automation, and that for self-propagating campaigns credential theft is no longer always the end state. Stolen tokens are fuel for the next round.

That combination changes the economics for any company that builds software. A typical web application pulls in hundreds or thousands of transitive dependencies. You will not out-review that tree by hand, and you cannot predict which trusted maintainer will be compromised next. What you can control is what your machines are willing to execute during an install, how quickly they accept brand new versions, and how much a single stolen credential is able to reach.

Regulation is moving in the same direction. If you sell software into Europe, the Cyber Resilience Act's reporting obligations, which we covered in our article on the CRA's September deadline, mean an actively exploited compromise in your product's dependency chain is no longer only an internal incident. Knowing within hours whether you installed an affected version is becoming a compliance capability, not just good hygiene.

What Has Actually Changed in the Tooling?

The good news is that the package managers have finally changed their defaults in ways that would have blunted this attack. The biggest is npm 12. GitHub's changelog for the release explains that npm install no longer runs preinstall, install or postinstall scripts from dependencies unless the project allows them, and that git and remote-URL dependencies no longer resolve unless explicitly permitted. Teams approve trusted packages with npm approve-scripts and commit the resulting allowlist to package.json. The Hacker News reported the release in July 2026.

pnpm got there first and goes further. Its dependency resolution settings include minimumReleaseAge, which defines the minimum number of minutes that must pass after a version is published before pnpm will install it, and which defaults to 1,440 minutes, one day, since pnpm 11. A trustPolicy of no-downgrade makes installs fail if a package's trust level has decreased compared with previous releases, and blockExoticSubdeps stops transitive dependencies pulling code from git repositories or raw tarball URLs. A cooldown is exactly the soak period Elastic recommends before adopting new package versions: poisoned releases tend to be flagged by security researchers soon after publication, so a team that waits a day gives the ecosystem time to catch them before they reach its builds.

Publishing has tightened as well. GitHub permanently revoked all npm classic tokens in December 2025, and npm login now issues two-hour session tokens. According to The Hacker News, granular tokens are scheduled to lose the ability to publish directly in January 2027, leaving trusted publishing or a staged publish that becomes public only after human 2FA approval. That matters because, as Elastic notes, ChainDrop's propagation requires an npm token with write permission that can publish without 2FA.

None of these defaults help a team that has not upgraded. Many CI images still pin older Node.js and npm versions, plenty of repositories carry an .npmrc written years ago, and automation tokens with 2FA bypass are still common in release pipelines. The tooling has moved. Most codebases have not.

A Hardening Plan for the Next 30 Days

Start with execution. Upgrade developer machines and CI images to npm 12 or pnpm 11, run a normal install, and work through the list of packages that want to run scripts. In most web applications the legitimate list is short, usually a handful of native modules and tools like esbuild or image libraries. Approve those explicitly, commit the allowlist, and make CI fail if the list changes without review. Teams on older package managers can get most of the benefit with ignore-scripts set in a project-level configuration.

Next, add a cooldown. Configure minimumReleaseAge in pnpm, or use your dependency update bot's equivalent delay, so that new versions of third-party packages wait at least a day before they can land. Maintain a short exclusion list for your own internal packages and for genuine emergency patches. Pair this with lockfile discipline: CI installs from the lockfile only, and changes to the lockfile get reviewed like code rather than waved through as noise.

Then reduce what a single install can steal. CI jobs that install dependencies should not have publishing rights, cloud admin credentials or broad GitHub tokens in their environment. Split install, test and release into separate jobs with separate permissions, move publishing to trusted publishing, and remove any automation token that bypasses 2FA. On developer laptops, keep long-lived cloud keys out of plain-text files where possible; our article on credential sprawl in the agent era covers the patterns that work.

Finally, protect the files that run themselves. Add .claude/, .vscode/, .devcontainer/ and git hook directories to CODEOWNERS, require review from a named owner for changes to them, and alert on commits that touch them from automation accounts. Search your organisation's repositories now for commits authored as claude with the message chore: update config, which Elastic identifies as the worm's signature.

What Should You Do if an Affected Version Was Installed?

The guidance from responders is consistent and uncomfortable. BleepingComputer's summary advises treating any workstation or CI/CD runner that installed an affected version as compromised, even if the package was later removed, and rebuilding from safe backups or from scratch. Singapore's CSA gives the same instruction in its advisory: treat affected systems as potentially compromised and rebuild them.

Credential rotation has to be broad, because the stealer was broad. That means npm and GitHub tokens, cloud keys, Kubernetes and Vault credentials, SSH keys, CI secrets and the API keys for AI tools. Order matters with the October variant: The Hacker News describes a monitor that wipes the home directory when the stolen GitHub token is revoked, so isolate or reimage the affected machine before revoking tokens from it, not after.

The hard part for most teams is the first question: did we install it at all? Answering that requires knowing which versions every repository, build image and developer machine resolved over the exposure window. Teams with lockfiles in version control, a software bill of materials per build and centralised CI logs can usually answer within an hour. Teams without them spend days reconstructing the picture while the stolen credentials remain live.

Run the exercise before you need it. Pick one historical malicious version, ask how long it would take to prove whether any system in your organisation installed it, and time the answer. The gap between that number and an hour is your real supply chain risk.

Why Does Dependency Hygiene Keep Slipping?

Nothing in the hardening plan is technically difficult. It slips because it belongs to nobody. Package manager upgrades, CI permission splits and CODEOWNERS rules sit between platform, security and product teams, and none of them is measured on completing it. Product engineers are measured on features, and a week spent approving install scripts and rewriting release pipelines looks like a week of no visible progress.

AI coding agents make the gap wider. Agents add dependencies quickly, update lockfiles as a side effect of unrelated changes and generate a steady stream of configuration commits, which trains reviewers to skim exactly the kinds of diff that ChainDrop hid inside. The volume of change has gone up, while the attention available for the boring files has not.

The teams that handle this well treat supply chain controls as a standing workstream with an owner, not as a reaction to the latest headline. The owner keeps package managers current, maintains the script allowlist and cooldown exclusions, reviews dependency and configuration changes, and runs the "did we install it?" drill each quarter. That is a small, continuous amount of work, which is precisely why it gets dropped when it has to compete with a roadmap.

How Stepto Helps Teams Harden Their Software Supply Chain

At Stepto, our engineers in Serbia build and maintain JavaScript and TypeScript systems for European and US clients every day, from React and Next.js front ends to Node.js services and AI product layers. Dependency hygiene is part of how we work on every engagement: lockfile-only CI installs, explicit install-script allowlists, release cooldowns, separated publishing credentials and reviewed changes to agent and editor configuration.

A dedicated development team from Stepto can take supply chain hardening on as a defined workstream inside your repositories: inventory your package managers and CI images, upgrade to npm 12 or pnpm 11, design the script allowlist with your engineers, split CI permissions, move publishing to trusted publishing and put the self-executing configuration paths under ownership. Every change goes through senior review, and the work stays in your codebase and your pipelines, so the controls outlive the project.

The nearshore model matters during an incident as much as during the hardening. Our working day overlaps fully with European teams and substantially with the US East Coast morning, so when a new compromised package is announced, the people who know your dependency tree can check exposure, coordinate rotation and rebuild affected runners with your team in real time rather than a day later.

If you are not sure whether your pipelines would have installed ChainDrop, or how long it would take to find out, talk to us. A short review of your lockfiles, CI configuration and publishing setup is usually enough to show where the biggest gaps are.