ChainDrop shows why a package can have valid build provenance and still be malicious. The compromised Keyv maintainer account introduced poisoned source into the project’s legitimate GitHub Actions and npm trusted-publishing workflow. The resulting SLSA attestation accurately described how the package was built; it did not establish that the source change was authorized or safe.
What happened in the ChainDrop incident?
On August 4, 2026, an attacker used a compromised credential associated with the Keyv maintainer to push malicious changes into Keyv and related repositories. The first confirmed carrier in StepSecurity’s chronology was [email protected], published at 09:35 UTC through GitHub Actions OIDC trusted publishing with a valid SLSA attestation. StepSecurity’s incident analysis and maintainer Jared Wray’s account describe the release and response.
As an Amazon Associate I earn from qualifying purchases.
Wray said an old, full-access GitHub personal access token was active on an infected machine, but he could not be completely certain how the attacker obtained it. The initial access mechanism therefore remains uncertain; the evidence supports saying the credential was compromised, not asserting exactly how.
Recommended Free Tools
How the malicious release behaved
StepSecurity’s technical analysis says the package included a preinstall hook. Its documented dropper downloaded the Bun runtime and ran a credential-stealing payload. The analysis also describes propagation using stolen package-publishing credentials and persistence through VS Code and Claude Code project configuration. These are documented capabilities and findings, not proof that every capability ran in every affected environment.
#1 Best Overall
What remediation did—and did not—mean
Wray reported that by the end of August 4, known-clean versions of all eleven original package names had been restored to npm’s latest tag, and the exploit had been removed from every branch within 36 hours. Those are maintainer-reported remediation milestones. Restoring a package tag does not undo an earlier installation or establish that downstream systems are clean.
How many packages were affected?
Published counts are snapshots taken at different times and scopes, not confirmed numbers of compromised users or systems.
| Source and snapshot | Reported observation | What it means |
|---|---|---|
| StepSecurity, August 4, 2026, by 13:20 UTC | 2,201 versions across 433 additional packages | A dated observation of propagation; it is not a count of confirmed malicious installations. |
| Harness, August 2026 analysis, citing SafeDep and public reporting available at that time | 2,234 poisoned versions across 444 package names | A different snapshot and scope, not an uncontested final total. |
| StepSecurity, August 2026 incident analysis | [email protected] had 153.7 million weekly downloads |
Reported package reach at the time, not confirmed downloads of the malicious version or confirmed compromises. |
The differing totals are not necessarily contradictory: investigations can count at different times and use different scopes. None of these figures establishes how many systems actually installed or executed a poisoned version. See Harness’s August 2026 analysis for its account of the broader package count.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why did provenance and SLSA attestation not stop it?
Because provenance answers a narrower question than whether a release is trustworthy. It can connect an artifact to a source revision and build process. If malicious code has already entered the source that the legitimate process builds, an accurate attestation can faithfully describe the build of a malicious artifact.
In this case, the release pipeline was real and the provenance was valid. The poisoned source had entered the release path through a compromised maintainer credential. The attestation did not independently verify the maintainer’s intent, the authorization of the change, the quality of its review, or whether the resulting code behaved benignly.
Jared Wray, Keyv and Cacheable maintainer, wrote: “That distinction matters. Provenance proved where and how the package was built. It did not prove that the source was safe or that the change was authorized.”
What does software provenance actually prove?
Provenance is evidence about a component’s history and origin, not a blanket safety certificate. NIST SP 800-172r3 defines provenance broadly as the chronology of origin, development, ownership, location, and changes to a system component and its associated data. NIST separately discusses “pedigree” as validating the internal composition and provenance of critical technologies, products, and services.
That distinction is useful in practice: a trustworthy record of origin and changes helps answer where an artifact came from and how it was produced. A trust decision also needs evidence that the changes were authorized and that the artifact’s composition and behavior are acceptable. NIST’s publication is general guidance, not an investigation of ChainDrop.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should teams check alongside provenance?
Use provenance as one evidence layer, then apply controls to the other trust questions it cannot settle. The checks below cover different stages; none guarantees prevention on its own.
1. Verify that source changes were authorized
- Require review and approval for changes, including changes to release scripts, package manifests, workflow files, editor tasks, and agent configuration.
- Use branch protections and independent review so a compromised account cannot quietly turn an unapproved change into a release.
2. Match the artifact to the expected release
- Check that the artifact maps to the expected repository, approved commit, pull request, tag, and workflow version.
- Investigate unexpected release changes. A valid signature or attestation should be evidence to examine, not an override for mismatches.
3. Control dependency installation and execution
- Assess whether a new dependency version is expected and whether it introduces a lifecycle script or other unexpected behavior.
- Disable lifecycle scripts in CI when they are not required. Where they are required, isolate and monitor their execution.
4. Limit credential exposure
- Give build systems and developer machines access only to the publishing credentials, cloud secrets, and production systems they need.
- Prefer short-lived, least-privilege credentials and disposable isolated runners to reduce the reach of a compromise.
5. Prepare for investigation and recovery
- If an affected version ran, inspect for persistence and unexpected changes to repositories or workflows.
- Rotate exposed credentials from a clean environment, and rebuild affected systems as appropriate.
- Use current incident-specific advisories for affected versions and indicators rather than assuming that restoring a package release cleaned downstream environments.
What is the practical takeaway?
ChainDrop was not evidence that provenance failed to describe a build. It was evidence that a truthful account of a build cannot, by itself, establish that the source entering that build was authorized or safe. Trust decisions need controls at the source-change, dependency-intake, build, installation, credential-access, and runtime stages—each addressing a different part of the risk.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
