Vulnerabilità SP1: Succinct corregge un bug che faceva passare prove non valide, ma Groth16 e Plonk on-chain erano al sicuro

Succinct, la società che sviluppa la zkVM SP1, ha reso nota una vulnerabilità di SP1 di gravità alta: in alcune versioni, dalla 6.0.0 alla 6.8.0, una prova malformata poteva superare pool di un market maker automatico divergono, rispetto a tenere semplicemente gli stessi token. Diventa definitiva al prelievo.">il verificatore nativo in Rust. L’avviso di sicurezza GHSA-p7v2-jjv3-8p8f su GitHub è stato pubblicato l’11 ottobre 2026; la correzione, la versione 6.8.1, era uscita il 24 settembre. I verificatori on-chain Groth16 e Plonk non sono stati toccati e né Succinct né la stampa hanno segnalato exploit o perdite di fondi.

La notizia è arrivata ai media solo venerdì 23 ottobre, quando The Defiant ha raccontato la patch, subito ripresa da aggregatori come il flash di KuCoin e ChainCatcher. Non si tratta quindi di una scoperta di oggi: è una divulgazione rimasta su GitHub per dodici giorni, relativa a una correzione che aveva quasi un mese quando la stampa se n’è accorta.

Il perimetro è ristretto. Il difetto stava nel codice Rust che controlla le prove fuori dalla blockchain. I contratti Solidity che rollup e bridge usano su Ethereum, quelli che in concreto custodiscono il denaro, verificano un altro tipo di prova e restavano fuori portata.

Che cos’era la vulnerabilità di SP1: un contenitore di dati con l’etichetta sbagliata

Dentro il verificatore, SP1 conserva i dati della prova in oggetti chiamati tensori: un buffer piatto più un insieme di dimensioni dichiarate che indicano come leggerlo. Un tensore di dimensioni 4 per 8 dovrebbe contenere esattamente 32 valori.

Secondo l’avviso, al momento della deserializzazione, cioè quando i byte grezzi vengono riconvertiti in questi oggetti, nulla controllava quella regola. Un prover malevolo poteva inviare un tensore la cui lunghezza reale non corrispondeva al prodotto delle dimensioni. Le diverse fasi della verifica leggevano allora parti diverse degli stessi dati e il verificatore nativo in Rust poteva finire per accettare la prova di un’esecuzione non valida.

L’avviso si intitola «SP1 V6 Native Rust Verifier: Mismatched Tensor Lengths» e classifica il problema come grave. Non è stato assegnato alcun numero CVE. I crate Rust indicati come colpiti sono tre, sp1_prover, sp1_hypercube e sp1_sdk, tutti dalla versione 6.0.0 fino alla 6.8.0 inclusa.

La correzione è semplice nel principio. La versione 6.8.1 aggiunge un controllo di lunghezza alla deserializzazione, così un tensore la cui dimensione non coincide con le sue dimensioni dichiarate viene rifiutato, e aggiunge controlli sulla forma lungo i percorsi del verificatore.

Che cos’è una prova zkVM e che cosa significa soundness

Una zkVM, ovvero macchina virtuale a conoscenza zero, esegue un programma ordinario e produce una breve prova crittografica del fatto che sia stato eseguito correttamente. Chi ha la prova può verificarla in una frazione del tempo che servirebbe per rieseguire il programma. La nostra voce del glossario sulle prove a conoscenza zero spiega l’idea di fondo.

I progetti usano zkVM come SP1 per dimostrare che un gruppo di transazioni è stato elaborato in modo corretto: è così che un rollup a conoscenza zero convince Ethereum che il suo stato è giusto senza che Ethereum debba rieseguire tutto.

Due proprietà rendono utile un sistema simile. La completezza (completeness) vuol dire che una prova onesta passa sempre. La solidità (soundness) vuol dire che una prova falsa non passa mai. Un bug di soundness è il tipo più pericoloso: il controllore può essere ingannato e indotto ad approvare un risultato sbagliato.

Se un verificatore ingannato fosse l’unico ostacolo tra gli utenti e i loro fondi, un aggressore potrebbe in teoria dimostrare un prelievo o un saldo falsi. Per questo la riga più rassicurante dell’avviso è quella che dice quali verificatori non erano coinvolti.

Solo il verificatore nativo in Rust era esposto, non Groth16 né Plonk on-chain

SP1 produce diversi tipi di prove. Le prove Core e Compressed sono voluminose e vengono controllate via software, di norma dal verificatore nativo in Rust. Per l’uso su una blockchain, SP1 le avvolge in prove Groth16 o Plonk, piccole, di forma fissa e verificate da contratti Solidity.

L’avviso di Succinct precisa che il bug riguardava le prove Core e Compressed inviate direttamente al verificatore nativo in Rust. Le prove Groth16 e Plonk non erano interessate, perché la loro forma fissa non lascia spazio a un tensore incoerente. Anche le prove Compressed controllate tramite la funzione di libreria verify_sp1_proof erano al sicuro, ma solo quando l’aggregazione termina con una prova Groth16 o Plonk.

Per sfruttare il difetto, un aggressore doveva poter inviare prove a un verificatore nativo in Rust che le accettasse dall’esterno. Le implementazioni in cui il controllo finale avviene on-chain, tramite un contratto Groth16 o Plonk, restavano fuori da questo caso.

Chi era esposto e che cosa non si sa ancora

Succinct indica una sola implementazione. «At the time of the finding, the only known affected deployment was the Succinct-operated mainnet Prover Network», cioè al momento della scoperta l’unica implementazione nota come colpita era la Prover Network mainnet gestita da Succinct, scrive l’avviso. Quella rete è un mercato in cui prover terzi generano prove per richiedenti paganti, quindi accettava davvero prove dall’esterno.

Succinct afferma di aver aggiornato la Prover Network mainnet e che i richiedenti non devono cambiare nulla. Aggiunge che l’esposizione di un richiedente dipendeva dalla modalità di prova e dal percorso seguito, senza fornire un dettaglio. L’avviso dice che la correzione è arrivata sulla Prover Network dopo il rilascio della v6.8.1, ma non indica la data di quel dispiegamento.

Restano aperte diverse domande. Succinct non ha detto se qualcuno abbia inviato una prova malformata alla Prover Network prima della correzione, né per quanto tempo il codice vulnerabile sia rimasto attivo. Non ha detto quali progetti esterni, se ce ne sono, facessero girare un proprio verificatore nativo in Rust su prove di parti non fidate. Coindaro non ha trovato dichiarazioni di utenti di SP1 come OP Succinct o Mantle su esposizione o aggiornamenti, e non ne presumiamo alcuna.

Succinct attribuisce la scoperta a Vitalis Salis, tramite il programma di bug bounty su Immunefi. Non è stato pubblicato alcun importo della ricompensa e nemmeno il resoconto di The Defiant ne fornisce uno.

La correzione è uscita 16 giorni prima dell’avviso

La release v6.8.1 è stata pubblicata su GitHub il 24 settembre 2026 alle 18:47 UTC. Le note pubbliche elencano un «checked addition for global sum» e altre correzioni, ma nessuna voce di sicurezza. Chi seguiva le release poteva aggiornare più di due settimane prima che i dettagli del difetto fossero pubblici.

Da allora Succinct ha pubblicato la v6.9.0 il 10 ottobre alle 01:20 UTC, il giorno prima dell’avviso, e la v6.10.0 il 23 ottobre alle 15:31 UTC, il giorno in cui la stampa ha ripreso la storia.

Che cosa devono controllare i progetti e gli sviluppatori che usano SP1

Per la maggior parte di chi usa applicazioni costruite su SP1 non cambia nulla: se l’unico controllo che conta è un verificatore Groth16 o Plonk on-chain, questo bug non si applicava. Per i team che sviluppano con SP1, l’avviso suggerisce una breve lista di verifiche.

• Accertarsi se qualche servizio chiama il verificatore nativo in Rust di sp1_prover, sp1_hypercube o sp1_sdk su prove non generate da voi.
• In tal caso, se usate una versione dalla 6.0.0 alla 6.8.0, aggiornare alla 6.8.1 o successiva. Anche le release 6.9.0 e 6.10.0 includono la correzione.
• Se verificate in modo ricorsivo prove Compressed con verify_sp1_proof, controllare che l’aggregazione termini con una prova Groth16 o Plonk.
• Se vi limitate a richiedere prove alla Prover Network di Succinct, secondo Succinct non serve alcuna azione.

Sei avvisi su SP1 in due anni, tutti legati a un controllo mancante

Non è il primo problema di soundness di SP1. Ogni avviso presente sulla pagina GitHub del progetto descrive un controllo o un vincolo che il verificatore avrebbe dovuto imporre e non imponeva. Sono stati individuati in modi diversi: dal ricercatore rkm0959, da un audit di Zellic commissionato da Succinct, dal team stesso di Succinct e tramite bug bounty su Code4rena e Immunefi.

L’episodio di gennaio 2025 fu il più grave. Un aggiornamento di sicurezza sul blog di Succinct datato 27 gennaio 2025, firmato da John Guibas, descriveva due bug in SP1 V3 e uno in Plonky3, che il testo definisce una delle dipendenze fondamentali di SP1. Tutti e tre furono corretti in SP1 Turbo e i router verso i contratti verificatori di SP1 sulle mainnet vennero congelati. Un bug lo trovò Succinct stessa. Un team di Aligned, LambdaClass e 3MI Labs segnalò il secondo, che Succinct aveva individuato anche in modo indipendente, mentre i ricercatori Lev Soukhanov e Onur Kilic scoprirono il difetto di Plonky3. I contributori furono pagati tramite i programmi di bug bounty di Succinct o di Polygon, con importi non divulgati, e il post non indicava alcuna cifra di fondi a rischio. Il supporto a V2 e V3 sulla Prover Network è terminato il 15 febbraio 2025.

Ad aprile 2026, il vuoto nel legame del conteggio righe, scoperto tramite il bug bounty di Succinct su Code4rena, riguardava le prime release 6.0. Succinct disse allora di non aver dimostrato un exploit completo capace di provare affermazioni arbitrarie.

Il caso attuale è meno serio di quello di gennaio 2025: non era coinvolto alcun verificatore on-chain e l’avviso non cita router congelati. Arriva nella stessa settimana di un altro dibattito su quando rendere pubbliche le correzioni di sicurezza: la modifica di Bitcoin Core al suo embargo sulla divulgazione. Per chi si chiede dove stiano davvero i punti deboli dei sistemi crypto, la nostra guida su se una blockchain può essere hackerata chiarisce la differenza tra il protocollo e il software che lo circonda.

Nessuna reazione di prezzo documentata per PROVE

Il token PROVE di Succinct, un ERC-20 a offerta fissa di 1 miliardo che i richiedenti usano per pagare le prove e i prover mettono in staking, non ha mostrato alcuna reazione che Coindaro possa collegare a un prezzo con orario verificato. Non pubblichiamo nessuna cifra.

Succinct non ha ancora detto se la sua Prover Network abbia ricevuto prove malformate prima che la patch fosse attiva. Nemmeno i team che usano verificatori SP1 propri su prove esterne hanno confermato un aggiornamento.