Security

SP1 clarification puts the verification path at the center of security review

L2BEAT says onchain Groth16 and Plonk verifiers were unaffected by the disclosed native Rust issue. Integrators need to identify the path their applications actually trust.

ETH Canal ·

Illustrated hands inspecting two separate tracks in a brass-and-wood mechanism.

L2BEAT clarified on Friday that the disclosed SP1 vulnerability affected native Rust verification, while onchain Groth16 and Plonk verification through Solidity verifiers was unaffected. That distinction matters more than treating every use of the same proving system as equally exposed.

Succinct’s underlying advisory, published earlier this month, describes malformed proof data whose declared dimensions disagree with its stored contents. It says the mainnet Prover Network received a fix and directs separately operated affected native verifiers to the patched release. The advisory is available at https://github.com/succinctlabs/sp1/security/advisories/GHSA-p7v2-jjv3-8p8f .

For a bridge, rollup or proof-consuming application, the useful question is which component makes the final acceptance decision. A native verification service and a wrapped proof checked by a Solidity contract can have different exposure, even when both sit within one product.

Teams should map proof mode, verifier implementation and software version before drawing conclusions from a product name. L2BEAT’s clarification narrows this incident’s scope; it does not certify every deployment or replace an integration-specific review.