🚨 Active supply chain attack on npm: keyv and cacheable are compromised right now, and the payload is a worm. The maintainer account behind both package families was compromised. On August 4, ten packages were republished with a malicious preinstall hook that steals your credentials, then uses those credentials to publish itself into more packages. Malicious versions are live on npm as I write this. These are foundational packages. keyv, cacheable, flat-cache, and file-entry-cache sit deep in dependency trees as transitive deps of common tooling like ESLint. Tens of millions of weekly downloads. Most affected users never installed them directly. What the payload does: • preinstall hook (setup.mjs) downloads a standalone Bun runtime and runs the second stage under it, sidestepping the host Node version and any Node-level monitoring • Harvests cloud and CI credentials: AWS/GCP/Azure keys, HashiCorp Vault tokens, Kubernetes service account tokens, GitHub Actions OIDC, and npm tokens • Repackages other npm packages with the same hook and republishes them through npm OIDC trusted publishing. This is what makes it a worm. • Exfiltrates over DNS and by committing stolen secrets to attacker-created GitHub repos • Plants autostart hooks in .claude and .vscode that execute when a developer or an AI coding agent opens the cloned repo. No npm install required. The detail worth sitting with: [email protected] shipped with a passing npm provenance attestation. The build pipeline faithfully attested a source that was already trojanized. Signature verification alone did not stop this. Socket’s AI scanner flagged the malicious setup.mjs hook. If you install anything in the keyv, @keyv, or cacheable scopes: • Pin to the last known-clean version and rebuild lockfiles by integrity hash. No caret or tilde ranges, no npm update. • Better: block the entire keyv, @keyv, and cacheable scope at your registry proxy until the account is confirmed clean. • Rotate and revoke every credential reachable from any host that ran install scripts. npm and GitHub tokens should be revoked, not just rotated. Developing story. Socket is updating the affected-package list as new versions appear. Full research report with IoCs: socket.dev/blog/popular-npm-… If you are dealing with this right now and want help, email [email protected] and we will spin up emergency white-glove assistance.

Chainguard received PHP’s fix for two critical RCEs under embargo, like every other distributor. On October 21 at 07:41 UTC, more than six hours before the coordinated release, it published built images containing that fix. The PHP Foundation’s postmortem says Chainguard unilaterally broke the embargo. From that point, any attacker could study the fix in binary form while every other PHP user was still waiting. CVE-2026-109618 and CVE-2026-109619 let attackers run code on web servers without logging in. PHP runs 69% of websites whose server-side language is known. The embargo was already under strain. The CVE IDs leaked the day before, and Calif accidentally posted an exploit video that evening. PHP pulled the release forward a day but held it until 14:00 UTC, because distributors were still packaging and an immediate release would have left many users without a clean way to update. Chainguard went first anyway. Chainguard CEO Dan Lorenc says several vendors in the disclosure had reported exploits in the wild, and that he notified the group right after making the call. He did not name the vendors or publish evidence. PHP’s security team found no working public exploit by release time. Lorenc has since apologized for the added stress on PHP’s maintainers. Chainguard’s disclosure policy allows it to shorten timelines when exploitation is active. The patch it shipped was PHP’s, shared under PHP’s embargo. In July, Lorenc wrote: “Pre-disclosure protection extends exactly as far as the people you can vet and hold to an embargo.” Coordinated disclosure only works if everyone holding the fix ships at the same moment. When one party goes early, the fix becomes a map for attackers, and the users still waiting carry the risk. PHP owned its part. Its postmortem calls the long delay in fixing the underlying bug, first spotted in a 2024 audit, “a structural failure.” It is asking the companies that run on PHP to fund more engine engineers. If you haven’t patched: update the PHP runtime itself, not just WordPress or your framework, to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Then restart your workers.