How severe is GHSA-c873-wfhp-wx5m?

No CVSS score has been assigned to GHSA-c873-wfhp-wx5m yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-c873-wfhp-wx5m?

GHSA-c873-wfhp-wx5m affects the following packages: sp1-stark (crates.io). Ecosystems affected: crates.io.

How do I fix GHSA-c873-wfhp-wx5m?

Update sp1-stark to 4.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c873-wfhp-wx5m is resolved across your whole dependency graph.

How do I detect GHSA-c873-wfhp-wx5m in my crates.io dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for sp1-stark. 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.

How do I mitigate GHSA-c873-wfhp-wx5m if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-c873-wfhp-wx5m?

O3 pinpoints whether GHSA-c873-wfhp-wx5m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-c873-wfhp-wx5m actively exploited in the wild?

No public exploit code has been indexed for GHSA-c873-wfhp-wx5m yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-c873-wfhp-wx5m published, and has it been updated?

GHSA-c873-wfhp-wx5m was published on January 15, 2025 and was last updated on January 28, 2025. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🦀 crates.io

GHSA-c873-wfhp-wx5m

SP1 has missing verifier checks and fiat-shamir observations

Published

Jan 15, 2025

Updated

Jan 28, 2025

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🦀sp1-stark

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

In SP1’s STARK verifier, the prover provided chip_ordering is used to fetch the index of the chips that have preprocessed columns. Prior to v4.0.0, the validation that this chip_ordering correctly provides these indexes was missing. In v4.0.0, this was fixed by adding a check that the indexed chip’s name is equal to the name stored in the verifying key’s chip information.

In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability.

This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers.

Furthermore, in the recursive verifier, the is_complete boolean flag is used to flag a proof of complete execution. Prior to v4.0.0, this flag was underconstrained in parts of our recursive verifier, such as the first layer of the recursion. In v4.0.0, this bug was fixed by adding appropriate calls to the assert_complete function, which constrains the correctness of the is_complete flag. This code was a part of the audit for v3.0.0. This bug affects the soundness of the Rust SDK for verifying compressed proofs, and the soundness of on-chain verifier for deferred proofs.

This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0.

Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3.

This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🦀crates.io	`sp1-stark`	all versions	4.0.0

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for sp1-stark. 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 sp1-stark to 4.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c873-wfhp-wx5m 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-c873-wfhp-wx5m 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-c873-wfhp-wx5m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

In SP1’s STARK verifier, the prover provided `chip_ordering` is used to fetch the index of the chips that have preprocessed columns. Prior to v4.0.0, the validation that this `chip_ordering` correctly provides these indexes was missing. In v4.0.0, this was fixed by adding a check that the indexed chip’s name is equal to the name stored in the verifying key’s chip information. In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive ver

O3 Security · Impact-Aware SCA

Is GHSA-c873-wfhp-wx5m in your dependencies?

O3 detects GHSA-c873-wfhp-wx5m across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works