GHSA-r2xv-vpr2-42m9 — v2
Fix: slsa-framework/slsa-verifier#705GHSA-r2xv-vpr2-42m9 is a security vulnerability in github.com/slsa-framework/slsa-verifier/v2. A fix is available for github.com/slsa-framework/slsa-verifier/v2 — see the affected versions and patch details below.
slsa-verifier vulnerable to mproper validation of npm's publish attestations
Real-World Exposure
github.com/slsa-framework/slsa-verifier/v2🐹github.com/slsa-framework/slsa-verifierReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
slsa-verifier<=2.4.0 does not correctly verify npm's publish attestations signature.
Proof of concept
Steps to reproduce:
curl -Sso attestations.json $(npm view @trishankatdatadog/supreme-goggles --json | jq -r '.dist.attestations.url')curl -Sso supreme-goggles.tgz "$(npm view @trishankatdatadog/supreme-goggles --json | jq -r '.dist.tarball')"- In
attestations.json, take the value addressed by thejqselector.attestations[0].bundle.dsseEnvelope.payload, base64decode it, tamper with it, base64encode that, and replace the original value with that. Save the file asattestations_tampered.json. Here is an example command to replace the package name with@attacker/malicious:jq -r ".attestations[0].bundle.dsseEnvelope.payload = \"$(jq -r '.attestations[0].bundle.dsseEnvelope.payload | @base64d' < attestations.json | jq '.subject[0].name = "pkg:npm/%40attacker/malicious"' | base64 -w0)\"" < attestations.json > attestations_tampered.json SLSA_VERIFIER_EXPERIMENTAL=1 slsa-verifier verify-npm-package supreme-goggles.tgz --attestations-path attestations_tampered.json --builder-id "https://github.com/actions/runner/github-hosted" --package-name "@trishankatdatadog/supreme-goggles" --package-version 1.0.5 --source-uri github.com/trishankatdatadog/supreme-goggles- The result is that
slsa-verifierfails to detect this tampering of the publish attestation (unlike with the provenance attestation) and returnsPASSED.
Impact
An attacker who controls what packages and attestations are shown to a user can associate a package with an arbitrary name and version that do not match what the user expects from the publish attestation. Furthermore, the package digest in the publish attestation need not match its counterpart in the provenance attestation. However, the attacker cannot associate the given package with an arbitrary source and builder that the user does not expect from the provenance attestation. Thus, the attacker could, for example, convince package managers to install authentic but older versions of packages that contain known, exploitable vulnerabilities.
Severity is considered low because 1) it does not invalidate the provenance and 2) support for npm is currently experimental.
Patches
Fixed by PR #705 and released in versions >=2.4.1.
Workarounds
There is no easy way for users to fix or remediate this vulnerability without upgrading, short of verifying npm's publish attestations themselves, and cross-verifying it against GHA's provenance attestations.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/slsa-framework/slsa-verifier/v2 | all versions | 2.4.1-rc.0go get github.com/slsa-framework/slsa-verifier/v2@v2.4.1-rc.0 |
| 🐹Go | github.com/slsa-framework/slsa-verifier | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/slsa-framework/slsa-verifier/v2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/slsa-framework/slsa-verifier/v2 to 2.4.1-rc.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r2xv-vpr2-42m9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-r2xv-vpr2-42m9 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-r2xv-vpr2-42m9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-r2xv-vpr2-42m9 in your dependencies?
O3 Security finds GHSA-r2xv-vpr2-42m9 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.