npm Supply-Chain Compromise of keyv and Related Packages: What Businesses Should Check

On August 4, 2026, malicious versions of several widely used npm packages, including the caching library keyv, were published to the npm registry. GitHub, which operates npm, added entries for the affected packages to its Advisory Database the same day and classified them as malware.

This was not a bug in the code that a patch fixes. It was a supply-chain incident: trusted packages were replaced, for a short period, by versions that carried credential-stealing code. Any business whose website, web application or mobile app backend is built with JavaScript tooling could have pulled one of those versions in without anyone on the team choosing to. If you work with a team on Node.js development, or on a React, Angular or React Native front end, it is worth confirming how your project was affected.

This article sets out what the official advisories say, what security researchers reported, and the questions an owner should put to their developers. It does not describe how the malware works.

What happened on August 4, 2026

The GitHub Advisory Database entry "Malware in keyv", published on August 4, 2026, lists keyv version 6.0.0 and later as affected and shows no patched version. Separate malware advisories published the same day cover related packages, including cacheable-request, cacheable, several packages in the @cacheable scope and around twenty packages in the @keyv scope.

The wording of these advisories is blunt. They state that any computer that has the package installed or running should be considered fully compromised, that all secrets and keys stored on it should be rotated immediately from a different computer, and that removing the package does not guarantee that all malicious software has been removed.

Researchers at Snyk report that the malicious releases were published between 09:35 and 10:28 UTC and that npm had begun removing versions by 11:11 UTC. Snyk identifies eleven malicious releases from the same maintainer account, among them keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6 and cache-manager 7.2.10, and names keyv 5.6.0, flat-cache 6.1.23 and file-entry-cache 11.1.5 as the clean prior releases. These details come from Snyk's analysis rather than from GitHub.

Why packages you have never heard of matter

Few businesses choose keyv or flat-cache deliberately. They are what developers call transitive dependencies: packages that other packages depend on. Snyk notes that the affected packages are dependencies of widely used tools such as ESLint, a standard code-quality tool in JavaScript projects. A modern web project can contain hundreds or thousands of such indirect packages.

That is what makes this type of incident different from an ordinary vulnerability. Your developers did not need to add anything new. A routine install or an automated dependency update during the exposure window could have fetched a malicious version on a developer laptop or on the build server.

What the malicious versions were after

According to Datadog Security Labs, the malicious code ran at install time, before any application code, and collected credentials from the machine: GitHub and npm tokens, cloud provider secrets, SSH keys and secrets available to build pipelines. Datadog also reports that it used stolen publishing tokens to add itself to other packages, which is how the incident spread from one maintainer's packages to hundreds of others in a single day. Datadog describes the maintainer's account as compromised and does not identify how the attacker first gained access.

The target, in other words, was your development and deployment environment rather than your live website's visitors. The risk to the business is what those credentials unlock: source code, cloud accounts, databases and the ability to publish software in your name.

Who needs to act

The exposure depends on timing and on how your project installs dependencies. A project that installed from a committed lock file, with versions pinned before August 4, would have kept receiving the older, clean versions. The npm documentation for the npm ci command explains that it installs from the lock file and exits with an error, instead of updating the lock, if the lock file and package.json disagree.

The projects at risk are those where an install or update on August 4, 2026 resolved fresh versions: a new project set up that day, a lock file regenerated, an automated dependency update merged, or a build that does not use a lock file at all. Because the spread reached many other packages, checking only for keyv is not sufficient; your developers should compare the project's dependencies against the full lists published in the GitHub Advisory Database and by the researchers.

One caution on version numbers: the affected ranges in the GitHub malware advisories are written broadly and differ by package. The cacheable-request entry, for example, lists 13.0.20 and below. Developers should read the advisory for each package they use alongside a researcher's version list rather than relying on a single number quoted here.

What this means for your business

If none of your systems installed an affected version, there is nothing to clean up, but you only know that if someone has checked. Ask for a clear yes or no with the evidence, such as lock file history and build logs for that date.

If an affected version was installed anywhere, the advisories leave little room for half measures. Treat that machine or build environment as compromised and rotate every credential it could reach. Uninstalling the package and moving on is not an adequate response, because the purpose of the malware was to copy secrets that remain valid after the package is gone.

If the exposed credentials gave access to systems holding personal data, discuss with your legal adviser whether any notification obligations arise in the US or the UK. That depends on the facts, and this article is not legal advice.

What to ask your developers

• Did any developer machine, build server or deployment pipeline install dependencies on August 4, 2026, and did any resolve an affected version? How was that verified?
• If yes, which credentials were present there, and have all of them been rotated from a clean machine, including cloud keys, registry tokens, repository tokens and database passwords?
• Do our builds install strictly from a committed lock file?
• Do we allow install-time scripts to run by default? The npm documentation describes an ignore-scripts setting that stops packages from running scripts during installation; is that practical for our project?
• How quickly do automated dependency updates get merged, and is there a waiting period before brand-new releases are adopted?
• Are build secrets scoped narrowly, so a compromised build can reach only what it needs?

None of these measures removes the risk entirely, and some carry a cost. Blocking install scripts can break packages that legitimately need them, and delaying updates also delays real security fixes. The aim is a deliberate policy, not an accidental one.

Not an isolated event

This was not the first npm supply-chain compromise of 2026. On April 20, 2026, the US agency CISA published an alert on a supply chain compromise of the Axios npm package, in which malicious versions of that widely used HTTP library were released on March 31, 2026. CISA's recommendations there overlap with the questions above: rotate exposed credentials, and configure npm to prevent script execution and to allow time for new packages to be vetted. We read the pattern as a signal for planning: dependency hygiene should be a standing part of maintaining software, not a reaction to a single headline.

Conclusion

The August 4, 2026 compromise of keyv and related npm packages put credential-stealing code into dependencies that sit, mostly unnoticed, inside a very large number of JavaScript projects. GitHub's advisories classify the affected versions as malware and advise treating any machine that installed them as fully compromised. For a business owner, the task is to get a verified answer on exposure, make sure credentials were rotated where needed, and agree a clear policy for how dependencies are installed and updated.

If you would like help reviewing how your application handles dependencies and build security, Entrant Technologies builds and maintains web applications, mobile apps and custom software. You can get in touch with our team to discuss it.