A new self-replicating worm called ChainDrop has been crawling through the npm ecosystem, infecting 444 packages and — crucially — evading the standard defences most teams rely on to catch exactly this kind of attack. It's a supply chain incident with a twist: this one spreads on its own.

What happened. ChainDrop is described as a variant of the Shai-Hulud family. It spreads by poisoning package tarballs and hooking into developer tooling — the scripts that run automatically when you install, build, or test a project. That's a clever vector because those hooks run with developer-level trust on developer machines, and most security tooling is watching for suspicious network calls or known malicious hashes, not for a worm quietly rewriting packages mid-install.

The 444 infected packages aren't all obscure. Supply chain attacks tend to punch above their weight because even a low-download package can sit in the dependency tree of something enormous. One poisoned utility in a build tool chain can propagate to thousands of downstream projects before anyone notices.

Why standard defences miss it. The evasion is the interesting part. Traditional npm security tooling looks for known-bad package names, suspicious maintainer accounts, or checksum mismatches against the registry. ChainDrop sidesteps this by spreading through the tarball mechanism itself — effectively travelling inside packages that were legitimate when published. It's less "malicious package" and more "package that has been made malicious after the fact, inside your own environment."

That's a meaningful distinction. It means point-in-time scans of your package-lock.json or yarn.lock won't catch an infection that happened after the lock was written. Software composition analysis tools that rely on registry-side integrity checks are similarly blind.

What it does once inside. Reporting indicates the payload operates via dev-tool hooks, which means the blast radius depends heavily on what access those tools have. In a typical developer workflow, that could include filesystem access, credentials stored in environment variables, and tokens cached by the build system. In a CI/CD pipeline, it could be significantly worse.

Why this matters beyond npm. We've seen supply chain attacks against npm before — from the SolarWinds-era wake-up call through to the steady drip of typosquatting campaigns. But a worm — something that actively replicates rather than waiting to be downloaded — is a step change in sophistication. The attack surface for npm is genuinely enormous: there are over three million packages on the registry, and the JavaScript ecosystem's culture of small, composable modules means the average production application pulls in hundreds of transitive dependencies.

For Australian organisations, npm packages underpin a significant share of web and internal tooling. The ASD's Essential Eight doesn't call out supply chain integrity directly, but the ACSC has flagged software supply chain risk as a priority — and this is precisely the scenario that guidance warns about.

What to watch. GitHub's security team and the npm maintainers haven't yet published a full list of affected packages at time of writing — that's the immediate gap. Teams should audit recent installs, check for unexpected modifications to lock files, and review whether any lifecycle scripts (preinstall, postinstall, prepare) have changed in packages they didn't explicitly update. If you run a CI pipeline that auto-updates dependencies, pause and audit now.