Signed, and still yours — the npm worm that lives in your agent config

ChainDrop persists via AI coding-agent configuration files that no SBOM enumerates and no provenance attestation covers; the malicious releases were cryptographically attested by the projects' own release workflows, so signature validity proved build origin rather than authorisation.

Post

Your dependency scanner reads package.json. The worm that hit npm on Tuesday persists somewhere it will never look — inside your coding agent's config.

On 4 August Microsoft Threat Intelligence published its analysis of ChainDrop — tracked by Elastic as the return of Shai-Hulud. Eleven packages were seeded directly, keyv 6.0.0, flat-cache and file-entry-cache among them. Aikido counted 444 compromised packages across 1,381 versions by 5 August, over two billion monthly installs combined. The number is still moving; treat any count you read as a timestamp, not a total.

That is the part the headlines got.

Here is the part that should change your engineering, not your incident report.

The payload does not only run at install. Microsoft describes it injecting into .claude/settings.json and .vscode/tasks.json across repository branches. StepSecurity names the exact hooks: SessionStart in the Claude settings, runOn folderOpen in the VS Code task. Each executes a copy of the dropper.

So the reinfection trigger is not npm install. It is opening the repository in your agent.

Then the second thing.

These releases were not forged. The attacker took the maintainer's GitHub account, pushed poisoned commits and tags, and let the projects' own release workflows publish through OIDC trusted publishing. The malicious versions carry valid provenance attestations. The signature was real. It attested where the build ran — not who authorised it.

Hold that next to the Cyber Resilience Act. Annex I Part II requires a software bill of materials "in a commonly used and machine-readable format covering at the very least the top-level dependencies".

.claude/settings.json is not a dependency. Not in your SBOM. Not covered by the attestation. And it executes.

What I'd do Monday:

  1. Grep every repository for agent hook files — .claude/, .vscode/tasks.json, .cursor/, MCP server configs. Diff them against what you expect.

  2. Put agent config under code review. Config that executes is code — currently reviewed by nobody.

  3. Rotate credentials from a clean host. The infected one has your rotation in its shell history.

  4. Move to npm CLI v12 and set min-release-age. You cannot review what you install minutes after publication.

The CRA's reporting duty starts 11 September, thirty-six days out; the bill of materials duty in December 2027. Neither has a field for the file that owns you.

Which files in your repo execute before you have read a single line of them?

#SupplyChainSecurity #AgenticAI #CyberResilienceAct #AIEngineering #Berlin

First comment

Sources, primary first —

Microsoft Threat Intelligence, 4 August: the infection chain, and the injection into .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json and .vscode/setup.mjs as a secondary infection route https://www.microsoft.com/en-us/security/blog/2026/08/04/chaindrop-supply-chain-compromise-anatomy-self-propagating-worm/

Aikido, published 4 August and updated 5 August: the eleven seed packages with versions and monthly install counts, and the 444 packages / 1,381 versions figure https://www.aikido.dev/blog/keyv-and-friends-compromised-in-npm-supply-chain-attack

StepSecurity: names the exact hooks — SessionStart and runOn folderOpen — and documents the valid SLSA provenance via the maintainer's own release workflow https://www.stepsecurity.io/blog/chaindrop-npm-worm

Elastic Security Labs, tying ChainDrop to the earlier Shai-Hulud waves https://www.elastic.co/security-labs/shai-hulud-chaindrop-npm-supply-chain

Cyber Resilience Act, Annex I Part II — the SBOM duty quoted above https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Annex_1.html

One point cut for length: the package count is genuinely disputed. Aikido says 444 packages across 1,381 versions; StepSecurity says 433 across 2,201. Higher totals are circulating, but I could not get to a primary for them, so they are not here. It is a live worm and every number is a snapshot of the hour it was taken.

Claims

Sources

Corrections

None. Two figures were withheld rather than corrected: the aggregate package count (sources disagree) and an 89-second publication-to-impact figure (second-hand account of a conference talk).