GHSA-mhg6-2q2v-9h2c
HIGHsigstore-ruby verifier returns success for DSSE bundles with mismatched in-toto subject digest
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
sigstoreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Sigstore::Verifier#verify does not propagate the VerificationFailure returned by verify_in_toto when the artifact digest does not match the digest in the in-toto attestation subject. As a result, verification of DSSE bundles containing in-toto statements returns VerificationSuccess regardless of whether the artifact matches the attested subject.
Details
In lib/sigstore/verifier.rb, the verify method calls verify_in_toto (line 176) without capturing or checking its return value:
verify_in_toto(input, in_toto)
When verify_in_toto detects a digest mismatch, it returns a VerificationFailure object. Because the caller discards this return value, execution unconditionally falls through to return VerificationSuccess. This is the only verification sub-check in the method (out of 12) whose failure is not propagated.
The message_signature code path is not affected.
Impact
An attacker who possesses a valid signed DSSE bundle containing an in-toto attestation for artifact A can present it as a valid attestation for a different artifact B. All other verification checks (DSSE envelope signature, certificate chain, Rekor inclusion, SCTs, policy) pass because they are independent of the artifact content. Only the in-toto subject digest check detects the mismatch, and its result is discarded.
This allows an attacker to bypass artifact-to-attestation binding for any consumer that relies on Sigstore::Verifier#verify to validate DSSE/in-toto bundles.
Workarounds
None. Consumers cannot work around this without patching the library.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | sigstore | all versions | 0.2.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for sigstore. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update sigstore to 0.2.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mhg6-2q2v-9h2c 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 pinpoints whether GHSA-mhg6-2q2v-9h2c is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-mhg6-2q2v-9h2c. 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-mhg6-2q2v-9h2c in your dependencies?
O3 detects GHSA-mhg6-2q2v-9h2c across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.