Malware News On August 4, 2026 attackers compromised the GitHub account of the maintainer behind keyv a key-value storage library with 127 million weekly downloads

Khushal

Level 16
Thread author
Verified
Top Poster
Well-known
Apr 4, 2024
773
5,103
1,469
It also used that access to inject a credential-stealing worm across the entire package family. The same maintainer owns cacheable (29M downloads/month), flat-cache (565M downloads/month), file-entry-cache (557M downloads/month), and several other widely-used caching utilities, all of which were swept up in the same attack.

The compromise was carried out by pushing malicious files directly to the main branch and then immediately cutting a new release, meaning the poisoned versions were published to npm with valid provenance signed by GitHub Actions.

The compromised packages include:
  • keyv 6.0.0 (604M/month)
  • flat-cache 6.1.24 (580M/month)
  • file-entry-cache 11.1.6 (571M/month)
  • cacheable-request 13.0.20 (137M/month)
  • cacheable 2.5.1 (30M/month)
  • @cacheable/memory 2.2.1 (28M/month)
  • cache-manager 7.2.10 (16M/month)
  • @cacheable/node-cache 3.1.2 (6M/month)
  • @cacheable/utils 2.5.1 (34M/month)
  • @cacheable/net 2.1.1 (3.7K/month)
  • ecto 5.0.1 (4.5K/month)
We are also also seeing very active community spread of this supply chain worm to other maintainers and packages, including major organizations:

  • @deliveroo/reevent 1.0.1
  • @or-sdk/invitations 1.4.9
  • @picsart/ai-sdk 3.32.2
  • @qlik/embed-runtime 1.6.4
  • picasso.js 2.11.6
Update — August 4, 2026, 13:37 CEST: At least 434 packages (across 1381 versions) have been compromised by the worm, with a combined total of over 2 billion monthly installs at the time of writing.
 
Important qualification

I cannot independently verify the incident details or the stated package counts from the quoted text alone. The “August 4, 2026” update is also future-dated relative to the current date, so those figures should be checked against current primary sources before being treated as confirmed.

If these versions are confirmed as compromised, npm provenance or GitHub Actions signing does not make them safe. Provenance generally identifies how and where a package was built; it does not prove that the source or build process was free of malicious changes.

Recommended response for affected projects

  • Stop installing the listed versions and prevent them from entering CI/CD environments.
  • Check lockfiles, npm caches, package-manager logs, and deployment records for those exact versions.
  • Remove and reinstall dependencies from a trusted state after verifying safe versions and integrity hashes.
  • Rotate npm tokens, GitHub tokens, cloud credentials, signing keys, and other secrets available to affected build jobs.
  • Review CI/CD workflows and recent commits for unauthorized changes, especially scripts executed during installation or build steps.
  • Inspect outbound connections and newly created files or credentials on developer and build systems.
  • Submit suspicious package versions or artifacts to reputable security researchers and VirusTotal where appropriate.

Do not rely on npm audit alone. It may not immediately identify a newly published supply-chain compromise, and a clean result does not demonstrate that a package or host is unaffected.

The package names and versions should be confirmed through npm package histories, the maintainers’ official advisories, GitHub security notices, and independent analysis before broad claims about the total number of affected packages are repeated. Until that verification is available, treat the quoted list as an unconfirmed incident report and use the exact versions as indicators for investigation.