Keyv npm provenance attack shows the limit of a valid security attestation
A malicious Keyv release received genuine SLSA provenance because it passed through the project’s trusted GitHub Actions workflow.
By Renata Fuchs · Policy Reporter
· 3 min read
The Keyv npm provenance attack shows why a valid supply-chain attestation is not a malware verdict. On Aug. 4, 2026, a malicious version of the Keyv package, [email protected], was published through the project’s GitHub Actions release workflow after malicious code had entered its repository, according to Datadog Security Research. The release carried genuine SLSA provenance, binding the package to the very source revision and workflow that produced it.
That distinction is the important one for engineering and security teams. The provenance record was not forged, nor was it a fake cryptographic badge attached after publication. It accurately recorded a release path whose trusted source repository had already been altered.
Datadog’s timeline places the earliest recovered malicious Keyv state at 09:02:37 UTC. The unsigned commit added a preinstall mechanism, payload files, release configuration and a test that executed the loader. Later commits attributed to GitHub Actions added execution hooks aimed at Visual Studio Code and Claude-related directories across several branches.
What did Keyv’s provenance attestation verify?
Provenance establishes that a published artifact came from a specified source revision through a specified build process. It does not independently establish that the source code was reviewed, benign or untouched by an intruder before the build began.
For Keyv, Datadog reported that genuine SLSA provenance entered Rekor between 09:29:50 and 09:35:01 UTC. It linked [email protected] and tag v6.0.0 to malicious commit f97eabc, the project’s .github/workflows/release.yaml workflow and GitHub Actions run 30896232272. The confirmed malicious npm package published at 09:35:00.763 UTC.
That is useful evidence for incident response: a team can identify the precise revision, workflow and build run behind an artifact. It is not enough to decide whether to trust the artifact when the repository or the credentials operating its release process may have been compromised.
How did the malicious package run and spread?
When package-manager lifecycle scripts were permitted, npm invoked node setup.mjs through the package’s preinstall hook, Datadog said. Its analysis found the payload could query files, environment variables, runner memory and cloud secret stores. With valid npm or GitHub credentials, it could conditionally propagate to additional packages or repository branches.
The result is a more specific operational problem than unsigned packages alone. Signature and provenance checks can confirm that an artifact matches an automated release chain. Teams still need controls around source changes, maintainer credentials, workflow permissions and dependency rollout, because the trusted chain can faithfully ship malicious code.
Datadog also found that Keyv’s GitHub Release object was created after the npm publication and was not made public until 11:28:45 UTC. In this incident, a GitHub Release event was therefore not a reliable signal for when the npm artifact became available.
The Shai-Hulud name has been used for separate npm campaigns in 2025 as well as this Keyv-linked 2026 incident. The evidence here concerns the Aug. 4 Keyv release and its documented provenance sequence, not aggregate claims about those earlier campaigns.
This story draws on original reporting from VentureBeat.
