The recent compromise of the keyv library on npm illustrates how a credential‑stealing worm can bypass the very provenance checks meant to assure software supply‑chain integrity.
How the worm bypassed provenance
On Tuesday an attacker seized the GitHub account of the developer who maintains keyv, a small key‑value storage library that npm serves roughly 127 million times a week. Within hours, poisoned versions of keyv and its sibling caching packages appeared on npm, each carrying a worm that harvested credentials.
Security firm Aikido reported at least 868 compromised packages across 1,381 versions, totaling more than two billion monthly installs—a figure still climbing. JFrog independently traced the campaign to over 400 packages and 1,700 poisoned releases.
Related: Commerce AI’s Hidden Metric Flaw Sparks Industry Concern
The worm did not forge provenance signatures. Instead, it earned a legitimate attestation by pushing malicious files directly to the main branch of each repository the maintainer controlled and immediately cutting a new release. Because the release ran through the maintainer’s own GitHub Actions workflow, npm generated a valid provenance attestation for it.
To anyone auditing the supply chain, the poisoned build appeared authentic. In one documented path tied to the opensearch-js package, the attacker’s GitHub Actions run requested an OIDC token, exchanged it for a publish token, and minted a Sigstore bundle through Fulcio and Rekor. The resulting tarball carried provenance generated from the trusted workflow context itself.
Why the attack spread so fast
Once a poisoned package landed in a developer’s environment or a build runner, its payload harvested every credential it could reach, then used any npm publishing tokens it found to backdoor other packages the victim controlled. Each compromised maintainer became an unwitting distribution node, with dozens of newly infected packages appearing every few minutes, according to Aikido.
The malware exfiltrated stolen secrets to public GitHub repositories tagged “Shai‑Hulud: Here We Go Again,” a signature that named the campaign. Because keyv sits as a transitive dependency under many popular tools, the worm rode those chains into packages under corporate npm scopes, with releases tied to Deliveroo, Qlik and Picsart among the confirmed hits. Developers at those companies never installed keyv directly; it arrived as a deep dependency that few review manually.
Related: Google tests selfie videos for logins
Credential extractors inside the payload revealed the attackers’ true target: cloud access keys, CI secrets, and tokens that authenticate to production infrastructure. The package compromise was the vehicle; the cloud behind it was the destination.
From a broader perspective, the incident highlights a growing tension: the tools that accelerate development also accelerate risk. When supply‑chain security relies on attestations that verify a package’s build origin, the assumption is that the identity triggering the build is trustworthy. In this case, the attacker simply used a legitimate account to generate a flawless attestation, turning a defensive feature into a neutral conduit. That dynamic suggests that provenance alone cannot guarantee safety without robust identity controls.
Mitigations and industry response
GitHub, which owns npm, has taken steps to harden the registry. Two‑factor authentication is now mandatory for publishing, old never‑expiring tokens have been revoked, and trusted publishing allows build systems to push without stored credentials. npm 12, released mid‑2026, disables preinstall, install, and postinstall hooks by default, requiring explicit approval. Since the keyv worm executes through a preinstall script, npm 12 blocks its execution at install time.
However, the root cause remains the compromised maintainer account. Security engineer Kiran Raj of Endor Labs notes that most observed patterns involve an npm publishing token stolen and reused, often harvested from a CI or service‑account token on a build runner that had itself installed a poisoned dependency.
Related: Starlink unveils smaller home dish
Beyond technical controls, organizations are beginning to shift liability to supply‑chain partners. IEEE senior member Kayne McGladrey told VentureBeat that enterprises will increasingly contractually require vendors and maintainers to assume security responsibility, mirroring defense‑sector practices like CMMC certification.
For teams facing the fallout on Monday morning, the response can be organized around five governance actions: enforce provenance and trusted publishing for all dependencies, adopt a minimum release age, mandate phishing‑resistant MFA for all publishing accounts, rotate cloud credentials rapidly after any exposure, and compress patch windows to hours rather than days. Each step addresses a specific facet of the attack chain—automation, identity, cloud, and timing.
Package counts reported by Aikido and JFrog as of early August continue to climb, but the immediate threat is being contained. Compromised versions are being pulled, stolen tokens rotated, and affected packages republished clean. The longer‑term lesson is that the developer ecosystem itself is now a primary target, and the automation that makes it productive can also amplify a worm’s speed. Trust signals like provenance can be satisfied by anyone holding the right credentials; robust identity governance remains the missing piece.
