On August 4, 2026, an attacker gained control of the GitHub account belonging to the maintainer of keyv, a widely used key-value storage library, and used that access to push malicious commits directly to the main branch before cutting new releases. Because the releases were published through the maintainer's own account using GitHub Actions, they carried valid provenance signatures — nothing about the publishing process itself looked abnormal.

The malicious versions added a `preinstall` hook that ran an obfuscated loader before any application code executed, which then launched a larger second-stage payload. That payload was built to harvest cloud credentials, GitHub tokens, SSH keys, npm publishing tokens, and CI/CD secrets from the machine it ran on, and to use any credentials it found to republish the same malware into other packages the compromised developer maintained — the same self-spreading pattern seen in earlier "Shai-Hulud"-family npm attacks earlier in 2026.

Five packages maintained directly by the compromised account carried confirmed malicious versions: keyv, cache-manager, cacheable-request, @cacheable/utils, and flat-cache. Because those packages sit deep in the dependency tree of many other projects, the worm propagated further, ultimately touching more than 400 distinct npm packages downstream.

Clean versions were restored quickly: keyv 5.6.0, flat-cache 6.1.23, cache-manager 7.2.9, and cacheable-request 13.0.19 were confirmed safe and republished as the current "latest" tags for their respective packages. Any team that installed one of the affected packages on August 4 should treat every credential available to that build environment as potentially exposed and rotate accordingly, rather than assuming the malware's absence from a later `npm install` means nothing happened.

The incident is documented across the security research community, but as with most maintainer-account compromises, there is no single vendor press release to point to — the closest thing to an official record is the trail of GitHub advisories and the restored, verified package versions themselves, both viewable on the affected projects' own GitHub Advisory Database entries.

Source: GitHub Advisory Database