en
Back to the list

Succinct Patches SP1 Bug That Could Let Invalid Proofs Pass

source-logo  thedefiant.io 2 h
image

Succinct has patched a high-severity bug in its SP1 proof system that could allow a malicious prover to make the native Rust verifier accept a proof for an invalid program execution.

The project's Oct. 11 security advisory identifies versions 6.0.0 through 6.8.0 as affected and v6.8.1 as the patched version. Teams independently operating a native Rust verifier that accepts proofs from untrusted provers must upgrade to v6.8.1, Succinct said.

Succinct said it has already patched its mainnet Prover Network, with no integration changes required from requesters for that update. At the time of the finding, that network—which accepted proofs from third-party provers—was the only known affected deployment, according to the advisory.

Know when your
coins move

Alerts, real-time prices, and market news — all in one app
qr-code Point your phone camera to install
4.8 based on 40K reviews in the App Store and Google Play

SP1 is a zero-knowledge virtual machine that generates proofs that programs executed correctly. It supports programs written in Rust and other languages that compile to the RISC-V architecture.

Why Onchain Verification Was Unaffected

The vulnerability affected Core and Compressed proofs submitted directly to the native Rust verifier. Exposure therefore depended on how an application verified proofs, rather than simply whether it used SP1.

Onchain Groth16 and Plonk verification through Solidity verifiers was unaffected. The advisory explains that these paths use wrapped proofs with fixed shapes and do not process the proof-controlled Rust data representation involved in the bug.

The advisory also specifies a condition for applications verifying Compressed proofs through the `verify_sp1_proof` library function: they are unaffected only when proof aggregation ends with a Groth16 or Plonk proof.

The flaw involved tensors, data structures that pair a storage buffer with dimensions describing its shape. The number of stored elements should equal the product of those dimensions, but the verifier did not check that relationship when deserializing incoming data.

A malicious prover could supply mismatched dimensions and storage lengths, causing different verification stages to process different portions of the same tensor. That broke the consistency required for sound verification, according to the advisory, which credits Vitalis Salis with discovering the vulnerability through the Immunefi bug bounty program.

The patch checks tensor lengths during deserialization and adds physical-shape checks in the affected verification paths, rejecting malformed proofs rather than allowing verification stages to process inconsistent data.

thedefiant.io