The repository was real. The publishing workflow was trusted. The provenance checked out.
The package was malicious anyway. August brought us a worm with excellent paperwork—and a reminder that knowing where software came from is not the same as knowing it is safe.
So what do you do when the worm arrives with its paperwork in order? Start by making it wait five days. Then take a SIP: the Security Immediate Plan.
Welcome to Docker Security Dispatch 6, reviewing August 2026. This month: a worm with valid provenance, a defense that buys you time, and five controls for when you only have a few hours. Plus a poisoned macchiato, the Commandos' comic-book debut, and a CRA deadline that won't wait for your coffee break.
Key Takeaways Valid provenance proved which trusted workflow published ten malicious npm versions—not whether that workflow should have published them. Every worm campaign in the Shai-Hulud taxonomy was identified within five days, making a dependency cooldown a remarkably effective low-effort defense. SIP turns that first defense into five immediate controls across AI agents, dependencies, container builds, attestations, and release gates. EU Cyber Resilience Act reporting obligations begin on September 11, 2026.
We met Mini Shai-Hulud in April, when it compromised SAP-related npm packages and hunted developer credentials. In August, a new worm repeated the pattern, although its operator remains unknown.
On August 28, an attacker published ten malicious versions of @7nohe/openapi-react-query-codegen through the project's real GitHub Actions workflow. Any GitHub user could comment npm publish on a pull request; the workflow would check out that fork's code, install it, and run with id-token: write.
That's a bad idea. So, unauthorized code from a forked pull request was able to enter a trusted workflow, authenticate to npm through OIDC, and publish a malicious package. The workflow generated valid provenance, which pointed back to the real repository and the trusted workflow.
To read more about the Shai-Hulud family of worms, see my taxonomy of modern supply chain worms, which traces seven campaigns and the trust assumption each one broke.
The Node package manager has a configuration option called min-release-age. When set to a number of days, npm won't resolve any package version published within that many days. It is a simple, low-effort way to avoid the latest malicious releases. [[3]](https://docs.npmjs.com/cli/v12/using-npm/config/#min-release-age)
One CI caveat: npm ci installs versions already recorded in the lockfile, so the resolution-time cooldown does not re-check their age. Validate locked packages' publication dates before installing; SIP includes that check.
That one line changes the question from “Can my scanner recognize brand-new malware?” to “Has this release survived five days of public scrutiny?”
Why five days? If you look at the Shai-Hulud worm taxonomy, you'll see that every campaign was detected within five days. During that window, researchers unpack payloads, maintainers deprecate poisoned releases, registries remove tarballs, and security vendors publish detections. Your build does not need to win that race. It only needs to stay out of it.
Five days buys detection time; it does not make an old package safe. A patient attacker can leave a payload dormant beyond the waiting period, which is why the cooldown is a first defense, not the whole plan.
On the 6th of August, I appeared on SafeDev Talks to discuss AI agents installing dependencies.
At the end, I got this question: "What should we do, if we can only do a few things?"
My answer became SIP: the Security Immediate Plan, a five-control emergency plan I published ten days later, on August 16.
On August 21, Xygeni published The npm Worm Playbook, which compared three npm supply-chain incidents and singled out SIP's second control: combine a five-day cooldown with disabled lifecycle scripts. They called it a “genuinely sound, low-effort control” because it attacks the detection lag every fast-moving worm depends on. [[4]](https://xygeni.io/blog/npm-worm-playbook/)