What is GHSA-C873-WFHP-WX5M?

GHSA-C873-WFHP-WX5M is a high-severity security vulnerability in sp1-stark (rust), affecting versions < 4.0.0. It is fixed in 4.0.0.

Which versions of sp1-stark are affected by GHSA-C873-WFHP-WX5M?

sp1-stark (rust) versions < 4.0.0 is affected.

Is there a fix for GHSA-C873-WFHP-WX5M?

Yes. GHSA-C873-WFHP-WX5M is fixed in 4.0.0. Upgrade to this version or later.

Is GHSA-C873-WFHP-WX5M exploitable, and should I be worried?

Whether GHSA-C873-WFHP-WX5M 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.

What actually determines whether GHSA-C873-WFHP-WX5M 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.

GHSA-C873-WFHP-WX5M in sp1-stark

Q: Which versions of sp1-stark are affected by GHSA-C873-WFHP-WX5M?

sp1-stark (rust) versions < 4.0.0 is affected.

Q: Is there a fix for GHSA-C873-WFHP-WX5M?

Yes. GHSA-C873-WFHP-WX5M is fixed in 4.0.0. Upgrade to this version or later.

Q: Is GHSA-C873-WFHP-WX5M exploitable, and should I be worried?

Whether GHSA-C873-WFHP-WX5M 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.

Q: What actually determines whether GHSA-C873-WFHP-WX5M 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.

Q: How do I fix GHSA-C873-WFHP-WX5M?

Upgrade sp1-stark to 4.0.0 or later.

Summary

SP1 has missing verifier checks and fiat-shamir observations

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.

Impact

Affected versions

sp1-stark (< 4.0.0)

Security releases

sp1-stark → 4.0.0 (rust)

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 environment New to Kodem? Get a demo →

Remediation advice

Upgrade sp1-stark to 4.0.0 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

What is GHSA-C873-WFHP-WX5M? GHSA-C873-WFHP-WX5M is a high-severity security vulnerability in sp1-stark (rust), affecting versions < 4.0.0. It is fixed in 4.0.0.
Which versions of sp1-stark are affected by GHSA-C873-WFHP-WX5M? sp1-stark (rust) versions < 4.0.0 is affected.
Is there a fix for GHSA-C873-WFHP-WX5M? Yes. GHSA-C873-WFHP-WX5M is fixed in 4.0.0. Upgrade to this version or later.
Is GHSA-C873-WFHP-WX5M exploitable, and should I be worried? Whether GHSA-C873-WFHP-WX5M 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
What actually determines whether GHSA-C873-WFHP-WX5M 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.
How do I fix GHSA-C873-WFHP-WX5M? Upgrade sp1-stark to 4.0.0 or later.