Summary
A soundness vulnerability in SP1 V6 allows a malicious prover to supply proof tensors whose declared dimensions disagree with their storage length. This mismatch can cause the native Rust verifier to accept a proof for an invalid execution.
The vulnerability affects Core and Compressed proofs submitted directly to the affected native Rust verifier. Applications that use this verifier to accept proofs from untrusted provers are exposed to the issue.
Details
The verifier represents multidimensional data with a Tensor, which contains a storage buffer and dimensions that describe its shape. For verification to work correctly, the number of stored elements must equal the product of those dimensions.
During deserialization, the verifier did not check that the storage length matched the declared shape. Several verification paths then used the declared dimensions without checking the underlying storage.
A malicious prover could exploit these missing checks by supplying a tensor whose dimensions and storage length disagreed. Different verification stages could then process different portions of the same tensor, breaking the consistency required for sound verification.
Impact and Scope
Exploitation requires an attacker to submit proofs to the affected native Rust verifier. At the time of the finding, the only known affected deployment was the Succinct-operated mainnet Prover Network, which accepted proofs from third-party provers.
A malicious prover could submit a proof for an invalid execution that the network's affected verifier would accept. Requester exposure depends on the proof mode and verification path.
Groth16 and Plonk verification are unaffected because these paths use wrapped proofs with fixed shapes. They do not process the proof-controlled Rust Tensor representation involved in this vulnerability.
Applications that verify Compressed proofs through the verify_sp1_proof library function are unaffected by this issue only when proof aggregation ends with a Groth16 or Plonk proof.
Fix
The fix checks tensor lengths during deserialization and rejects tensors whose storage length differs from the product of their declared dimensions.
The affected native verifier paths also check the physical tensor shape before using the declared dimensions or processing stored elements. Together, these checks ensure that verification stages process the same elements and return an error for malformed proofs.
Succinct deployed the fix to the mainnet Prover Network after the v6.8.1 patched release became available.
Required Action
Succinct has updated the mainnet Prover Network to use the patched verifier. Requesters do not need to change their integration for this network update.
If you separately operate a native Rust verifier that accepts proofs from untrusted provers, upgrade to v6.8.1 .
Credit
This vulnerability was identified by Vitalis Salis through the Immunefi bug bounty program.
Summary
A soundness vulnerability in SP1 V6 allows a malicious prover to supply proof tensors whose declared dimensions disagree with their storage length. This mismatch can cause the native Rust verifier to accept a proof for an invalid execution.
The vulnerability affects Core and Compressed proofs submitted directly to the affected native Rust verifier. Applications that use this verifier to accept proofs from untrusted provers are exposed to the issue.
Details
The verifier represents multidimensional data with a
Tensor, which contains a storage buffer and dimensions that describe its shape. For verification to work correctly, the number of stored elements must equal the product of those dimensions.During deserialization, the verifier did not check that the storage length matched the declared shape. Several verification paths then used the declared dimensions without checking the underlying storage.
A malicious prover could exploit these missing checks by supplying a tensor whose dimensions and storage length disagreed. Different verification stages could then process different portions of the same tensor, breaking the consistency required for sound verification.
Impact and Scope
Exploitation requires an attacker to submit proofs to the affected native Rust verifier. At the time of the finding, the only known affected deployment was the Succinct-operated mainnet Prover Network, which accepted proofs from third-party provers.
A malicious prover could submit a proof for an invalid execution that the network's affected verifier would accept. Requester exposure depends on the proof mode and verification path.
Groth16 and Plonk verification are unaffected because these paths use wrapped proofs with fixed shapes. They do not process the proof-controlled Rust
Tensorrepresentation involved in this vulnerability.Applications that verify Compressed proofs through the
verify_sp1_prooflibrary function are unaffected by this issue only when proof aggregation ends with a Groth16 or Plonk proof.Fix
The fix checks tensor lengths during deserialization and rejects tensors whose storage length differs from the product of their declared dimensions.
The affected native verifier paths also check the physical tensor shape before using the declared dimensions or processing stored elements. Together, these checks ensure that verification stages process the same elements and return an error for malformed proofs.
Succinct deployed the fix to the mainnet Prover Network after the v6.8.1 patched release became available.
Required Action
Succinct has updated the mainnet Prover Network to use the patched verifier. Requesters do not need to change their integration for this network update.
If you separately operate a native Rust verifier that accepts proofs from untrusted provers, upgrade to v6.8.1 .
Credit
This vulnerability was identified by Vitalis Salis through the Immunefi bug bounty program.