Succinct, the company behind the SP1 zkVM, has disclosed a high-severity SP1 vulnerability that let a malformed proof pass the native Rust verifier in SP1 versions 6.0.0 to 6.8.0. The GitHub security advisory GHSA-p7v2-jjv3-8p8f was published on 11 October 2026; the fix, version 6.8.1, had shipped on 24 September. On-chain Groth16 and Plonk verifiers were not affected, and neither Succinct nor the press has reported any exploit or loss of funds.
The story reached the media only on Friday 23 October, when The Defiant reported the patch, followed by aggregators such as KuCoin’s news flash and ChainCatcher. So this is not a fresh discovery. It is a disclosure that sat on GitHub for twelve days, about a fix that was almost a month old when the press noticed it.
The scope is narrow. The bug lived in the Rust code that checks proofs off-chain. The Solidity verifier contracts that rollups and bridges use on Ethereum, the ones that actually gate money, check a different kind of proof and were out of reach.
What the SP1 vulnerability was: a mislabelled data container
Inside the verifier, SP1 stores proof data in objects it calls tensors: a flat storage buffer plus a set of declared dimensions that say how the buffer should be read. A tensor with dimensions of 4 by 8 should hold exactly 32 values.
Nothing checked that rule when a proof was deserialized, according to the advisory, meaning turned from raw bytes back into these objects. A malicious prover could send a tensor whose stored length did not match the product of its dimensions. Different stages of verification then read different parts of the same data, and the native Rust verifier could end up accepting a proof for an execution that was not valid.
Titled “SP1 V6 Native Rust Verifier: Mismatched Tensor Lengths”, the advisory rates the issue high. No CVE number has been assigned. Three Rust crates are listed as affected, sp1_prover, sp1_hypercube and sp1_sdk, all from version 6.0.0 up to and including 6.8.0.
The fix is simple in principle. Version 6.8.1 adds a length check at deserialization, so a tensor whose size disagrees with its dimensions is rejected, and adds shape checks along the verifier paths.
What a zkVM proof is, and what soundness means
A zkVM, or zero-knowledge virtual machine, runs an ordinary program and produces a short cryptographic proof that the program ran correctly. Anyone holding the proof can check it in a fraction of the time it would take to run the program again. Our glossary entry on zero-knowledge proofs explains the underlying idea.
Projects use zkVMs such as SP1 to prove that a batch of transactions was processed correctly, which is how a zero-knowledge rollup convinces Ethereum that its state is right without Ethereum re-executing everything.
Two properties make such a system useful. Completeness means an honest proof always passes. Soundness means a false proof never passes. A soundness bug is the dangerous kind: it means the checker can be tricked into approving a result that is wrong.
If a tricked verifier stood between users and their funds, an attacker could in theory prove a fake withdrawal or a fake balance. That is why the most reassuring line in the advisory is the one about which verifiers were not affected.
Only the native Rust verifier was exposed, not on-chain Groth16 or Plonk
SP1 produces several kinds of proofs. Core and Compressed proofs are large and are checked by software, typically the native Rust verifier. For use on a blockchain, SP1 wraps them into Groth16 or Plonk proofs, which are small, have fixed shapes and are checked by Solidity contracts.
Succinct’s advisory says the bug concerned Core and Compressed proofs submitted directly to the native Rust verifier. Groth16 and Plonk proofs were not affected, because their fixed shapes leave no room for a mismatched tensor. Compressed proofs checked through the verify_sp1_proof library function were also safe, but only when the aggregation ends in a Groth16 or Plonk proof.
To exploit the flaw, an attacker had to be able to send proofs to a native Rust verifier that accepted them from outside. Deployments whose final check happens on-chain, through a Groth16 or Plonk contract, fell outside that case.
Who was exposed and what is still unknown
Succinct names a single deployment. “At the time of the finding, the only known affected deployment was the Succinct-operated mainnet Prover Network,” the advisory says. That network is a marketplace where third-party provers generate proofs for paying requesters, so it did accept proofs from outsiders.
Succinct says it has updated the mainnet Prover Network and that requesters do not need to change anything. It adds that a requester’s exposure depended on the proof mode and the path the proof took, without giving a breakdown. The advisory says the fix reached the Prover Network after v6.8.1 became available, but gives no date for that deployment.
Several questions remain open. Succinct has not said whether anyone submitted a malformed proof to the Prover Network before the fix, nor how long the vulnerable code was live there. It has not said which outside projects, if any, ran their own native Rust verifier on proofs from untrusted parties. Coindaro found no statement from SP1 users such as OP Succinct or Mantle about exposure or upgrades, and we do not assume any.
Succinct credits the finding to Vitalis Salis, through the Immunefi bug bounty programme. No bounty amount has been published, and The Defiant’s report does not give one either.
The fix shipped 16 days before the advisory
The v6.8.1 release went out on GitHub on 24 September 2026 at 18:47 UTC. Its public notes list a “checked addition for global sum” and other fixes, but no security item. Anyone tracking releases could upgrade more than two weeks before the details of the flaw were public.
Since then Succinct has published v6.9.0 on 10 October at 01:20 UTC, the day before the advisory, and v6.10.0 on 23 October at 15:31 UTC, the day the press picked up the story.
| Date (2026) | Event |
|---|---|
| 24 September, 18:47 UTC | SP1 v6.8.1 released with the fix, no security note |
| 10 October, 01:20 UTC | SP1 v6.9.0 released |
| 11 October, 06:26 UTC | Advisory GHSA-p7v2-jjv3-8p8f published |
| 23 October | The Defiant reports the patch; aggregators follow |
| 23 October, 15:31 UTC | SP1 v6.10.0 released |
What projects and developers using SP1 should check
For most users of applications built on SP1, nothing changes: if the only check that matters is an on-chain Groth16 or Plonk verifier, this bug did not apply. For teams that build with SP1, the advisory points to a short checklist.
- Find out whether any of your services call the native Rust verifier from sp1_prover, sp1_hypercube or sp1_sdk on proofs you did not generate yourself.
- If they do and you run a version from 6.0.0 to 6.8.0, upgrade to 6.8.1 or later. Releases 6.9.0 and 6.10.0 also carry the fix.
- If you verify Compressed proofs recursively with verify_sp1_proof, check that your aggregation ends in a Groth16 or Plonk proof.
- If you only request proofs from the Succinct Prover Network, Succinct says no action is needed.
Six SP1 advisories in two years, each about a missing check
This is not the first soundness issue in SP1. Every advisory on the project’s GitHub page describes a check or constraint the verifier should have enforced and did not. They were found in different ways: by the researcher rkm0959, by a Zellic audit commissioned by Succinct, by Succinct’s own team, and through bug bounties on Code4rena and Immunefi.
| Published | Advisory | Severity | Fixed in |
|---|---|---|---|
| 28 Oct 2024 | GHSA-f77q-r5qm-w4m8, BabyBear range checks (found by rkm0959) | High | 1.2.0 |
| 8 Nov 2024 | GHSA-8m24-3cfx-9fjw, cumulative sum (found by rkm0959) | Medium | 3.0.0 |
| 15 Jan 2025 | GHSA-c873-wfhp-wx5m, missing verifier checks and Fiat-Shamir observations | High | 4.0.0 |
| 3 Jun 2025 | GHSA-6248-228x-mmvh, Plonky3, Rust verifier and allocators (Zellic audit) | High | 5.0.0 |
| 11 Apr 2026 | GHSA-63×8-x938-vx33 (CVE-2026-40323), recursion circuit row-count binding gap | High | 6.1.0 |
| 11 Oct 2026 | GHSA-p7v2-jjv3-8p8f, mismatched tensor lengths | High | 6.8.1 |
The January 2025 episode was the largest. A security update on Succinct’s blog dated 27 January 2025, signed by John Guibas, described two bugs in SP1 V3 and one in Plonky3, which the post calls one of SP1’s core dependencies. All three were patched in SP1 Turbo, and the routers to the SP1 verifier contracts on mainnets were frozen. Succinct found one bug itself. A team from Aligned, LambdaClass and 3MI Labs reported the second, which Succinct had also found independently, and the researchers Lev Soukhanov and Onur Kilic found the Plonky3 flaw. Contributors were paid through Succinct or Polygon bug bounty programmes, with amounts not disclosed, and the post gave no figure for funds at risk. Support for V2 and V3 on the Prover Network ended on 15 February 2025.
In April 2026, the row-count binding gap found through Succinct’s bug bounty on Code4rena affected early 6.0 releases. Succinct said then that it had not shown a full exploit able to prove arbitrary statements.
The current case is milder than January 2025: no on-chain verifier was involved, and the advisory mentions no frozen router. It lands in the same week as another debate on when security fixes should be made public: Bitcoin Core’s change to its disclosure embargo. For readers wondering where the real weak points of crypto systems sit, our guide on whether a blockchain can be hacked covers the difference between a protocol and the software around it.
No price reaction documented for PROVE
Succinct’s PROVE token, an ERC-20 with a fixed supply of 1 billion that requesters use to pay for proofs and provers stake, showed no reaction that Coindaro could tie to a timestamped price. We publish no figure.
Succinct has not yet said whether its Prover Network received any malformed proof before the patch went live there. Teams that run their own SP1 verifiers on outside proofs have not confirmed an upgrade either.