Faille SP1 : Succinct corrige un bug qui laissait passer des preuves invalides, sans toucher aux vérificateurs on-chain

Succinct, l’entreprise derrière la zkVM SP1, a révélé une faille de sévérité élevée qui permettait à une preuve malformée de passer le vérificateur Rust natif dans les versions 6.0.0 à 6.8.0 de SP1. L’avis de sécurité GitHub GHSA-p7v2-jjv3-8p8f a été publié le 11 octobre 2026 ; le correctif, la version 6.8.1, était sorti le 24 septembre. Les vérificateurs Groth16 et Plonk exécutés on-chain n’étaient pas concernés, et ni Succinct ni la presse ne font état d’un exploit ou d’une perte de fonds.

L’affaire n’est arrivée dans les médias que le vendredi 23 octobre, quand The Defiant a rapporté le correctif, suivi par des agrégateurs comme le flash d’actualités de KuCoin et ChainCatcher. pool di un market maker automatico divergono, rispetto a tenere semplicemente gli stessi token. Diventa definitiva al prelievo.">Il ne s’agit donc pas d’une découverte du jour. C’est une divulgation restée douze jours sur GitHub, à propos d’un correctif qui avait presque un mois quand la presse l’a remarqué.

Le périmètre est étroit. Le bug logeait dans le code Rust qui vérifie les preuves hors chaîne. Les contrats de vérification en Solidity que les rollups et les ponts utilisent sur Ethereum, ceux qui gardent réellement l’argent, contrôlent un autre type de preuve et restaient hors de portée.

La faille SP1 : un conteneur de données mal étiqueté

À l’intérieur du vérificateur, SP1 range les données d’une preuve dans des objets qu’il appelle « tenseurs » : un tampon de stockage à plat, accompagné de dimensions déclarées qui indiquent comment lire ce tampon. Un tenseur de dimensions 4 par 8 doit contenir exactement 32 valeurs.

Selon l’avis, rien ne vérifiait cette règle lors de la désérialisation d’une preuve, c’est-à-dire lors du passage des octets bruts à ces objets. Un prouveur malveillant pouvait envoyer un tenseur dont la longueur stockée ne correspondait pas au produit de ses dimensions. Les différentes étapes de la vérification lisaient alors des parties différentes des mêmes données, et le vérificateur Rust natif pouvait finir par accepter la preuve d’une exécution invalide.

Intitulé « SP1 V6 Native Rust Verifier: Mismatched Tensor Lengths », l’avis classe le problème en sévérité élevée. Aucun numéro CVE n’a été attribué. Trois crates Rust sont listées comme touchées, sp1_prover, sp1_hypercube et sp1_sdk, toutes de la version 6.0.0 jusqu’à la 6.8.0 incluse.

Le correctif est simple dans son principe. La version 6.8.1 ajoute un contrôle de longueur à la désérialisation, de sorte qu’un tenseur dont la taille contredit ses dimensions est rejeté, et ajoute des contrôles de forme sur les chemins de vérification.

Preuve zkVM et solidité : de quoi parle-t-on exactement

Une zkVM, ou machine virtuelle à divulgation nulle de connaissance, exécute un programme ordinaire et produit une courte preuve cryptographique attestant qu’il s’est déroulé correctement. Quiconque détient la preuve peut la contrôler en une fraction du temps qu’il faudrait pour relancer le programme. Notre fiche du glossaire sur les preuves à divulgation nulle de connaissance explique l’idée sous-jacente.

Les projets utilisent des zkVM comme SP1 pour prouver qu’un lot de transactions a été traité correctement. C’est ainsi qu’un rollup à divulgation nulle de connaissance convainc Ethereum que son état est juste, sans qu’Ethereum ait à tout réexécuter.

Deux propriétés rendent un tel système utile. La complétude veut qu’une preuve honnête passe toujours. La solidité (« soundness » en anglais) veut qu’une fausse preuve ne passe jamais. Un défaut de solidité est le plus dangereux : le vérificateur peut être trompé et approuver un résultat faux.

Si un vérificateur ainsi trompé se tenait entre des utilisateurs et leurs fonds, un attaquant pourrait en théorie prouver un faux retrait ou un faux solde. C’est pourquoi la ligne la plus rassurante de l’avis est celle qui précise quels vérificateurs n’étaient pas touchés.

Seul le vérificateur Rust natif était exposé, pas Groth16 ni Plonk on-chain

SP1 produit plusieurs types de preuves. Les preuves Core et Compressed sont volumineuses et vérifiées par un logiciel, typiquement le vérificateur Rust natif. Pour un usage sur une blockchain, SP1 les enveloppe dans des preuves Groth16 ou Plonk, petites, de forme fixe, et contrôlées par des contrats Solidity.

L’avis de Succinct indique que le bug concernait les preuves Core et Compressed soumises directement au vérificateur Rust natif. Les preuves Groth16 et Plonk n’étaient pas touchées, car leur forme fixe ne laisse aucune place à un tenseur de longueur incohérente. Les preuves Compressed vérifiées via la fonction de bibliothèque verify_sp1_proof étaient aussi à l’abri, mais seulement lorsque l’agrégation se termine par une preuve Groth16 ou Plonk.

Pour exploiter la faille, un attaquant devait pouvoir envoyer des preuves à un vérificateur Rust natif qui les acceptait de l’extérieur. Les déploiements dont le contrôle final se fait on-chain, par un contrat Groth16 ou Plonk, sortaient de ce cas de figure.

Qui était exposé, et ce que l’on ignore encore

Succinct désigne un seul déploiement. « Au moment de la découverte, le seul déploiement touché connu était le Prover Network mainnet exploité par Succinct », écrit l’avis. Ce réseau est une place de marché où des prouveurs tiers génèrent des preuves pour des demandeurs payants ; il acceptait donc bien des preuves venues de l’extérieur.

Succinct affirme avoir mis à jour le Prover Network mainnet et indique que les demandeurs n’ont rien à modifier. Elle ajoute que l’exposition d’un demandeur dépendait du mode de preuve et du chemin emprunté, sans fournir de détail. L’avis précise que le correctif a atteint le Prover Network après la mise à disposition de la v6.8.1, mais ne donne pas de date pour ce déploiement.

Plusieurs questions restent ouvertes. Succinct n’a pas dit si quelqu’un avait soumis une preuve malformée au Prover Network avant le correctif, ni combien de temps le code vulnérable y était resté en ligne. Elle n’a pas dit non plus quels projets extérieurs, s’il y en a, faisaient tourner leur propre vérificateur Rust natif sur des preuves de parties non fiables. Coindaro n’a trouvé aucune déclaration d’utilisateurs de SP1 comme OP Succinct ou Mantle sur une éventuelle exposition ou une mise à jour, et nous n’en supposons aucune.

Succinct attribue la découverte à Vitalis Salis, via le programme de bug bounty d’Immunefi. Aucun montant de prime n’a été publié, et le compte rendu de The Defiant n’en donne pas non plus.

Le correctif est sorti 16 jours avant l’avis

La version v6.8.1 est parue sur GitHub le 24 septembre 2026 à 18 h 47 UTC. Ses notes publiques mentionnent une « checked addition for global sum » et d’autres corrections, mais aucun point de sécurité. Quiconque suivait les versions pouvait donc mettre à jour plus de deux semaines avant que les détails de la faille ne soient publics.

Depuis, Succinct a publié la v6.9.0 le 10 octobre à 01 h 20 UTC, la veille de l’avis, puis la v6.10.0 le 23 octobre à 15 h 31 UTC, le jour où la presse a repris l’histoire.

Ce que les projets et développeurs qui utilisent SP1 doivent vérifier

Pour la plupart des utilisateurs d’applications bâties sur SP1, rien ne change : si le seul contrôle qui compte est un vérificateur Groth16 ou Plonk on-chain, ce bug ne s’appliquait pas. Pour les équipes qui développent avec SP1, l’avis dessine une courte liste de vérifications.

• Déterminez si l’un de vos services appelle le vérificateur Rust natif de sp1_prover, sp1_hypercube ou sp1_sdk sur des preuves que vous n’avez pas générées vous-mêmes.
• Si c’est le cas et que vous utilisez une version de la 6.0.0 à la 6.8.0, passez à la 6.8.1 ou à une version ultérieure. Les versions 6.9.0 et 6.10.0 embarquent aussi le correctif.
• Si vous vérifiez des preuves Compressed de façon récursive avec verify_sp1_proof, assurez-vous que votre agrégation se termine par une preuve Groth16 ou Plonk.
• Si vous vous contentez de demander des preuves au Succinct Prover Network, Succinct indique qu’aucune action n’est nécessaire.

Six avis de sécurité SP1 en deux ans, chacun sur un contrôle manquant

Ce n’est pas le premier problème de solidité dans SP1. Chaque avis publié sur la page GitHub du projet décrit un contrôle ou une contrainte que le vérificateur aurait dû imposer et n’imposait pas. Ils ont été trouvés de façons diverses : par le chercheur rkm0959, par un audit de Zellic commandé par Succinct, par l’équipe de Succinct elle-même, et via des bug bounties sur Code4rena et Immunefi.

L’épisode de janvier 2025 fut le plus lourd. Une mise à jour de sécurité publiée sur le blog de Succinct le 27 janvier 2025, signée John Guibas, décrivait deux bugs dans SP1 V3 et un dans Plonky3, que l’article range parmi les dépendances centrales de SP1. Les trois ont été corrigés dans SP1 Turbo, et les routeurs vers les contrats de vérification SP1 ont été gelés sur les mainnets. Succinct a trouvé l’un des bugs elle-même. Une équipe d’Aligned, de LambdaClass et de 3MI Labs a signalé le deuxième, que Succinct avait aussi repéré de son côté, et les chercheurs Lev Soukhanov et Onur Kilic ont trouvé la faille de Plonky3. Les contributeurs ont été rémunérés via les programmes de bug bounty de Succinct ou de Polygon, sans que les montants soient divulgués, et l’article ne chiffrait pas les fonds en jeu. Le support de V2 et V3 sur le Prover Network a pris fin le 15 février 2025.

En avril 2026, le défaut de liaison du nombre de lignes, découvert grâce au bug bounty de Succinct sur Code4rena, touchait les premières versions 6.0. Succinct avait alors indiqué ne pas avoir démontré d’exploit complet capable de prouver des énoncés arbitraires.

Le cas actuel est plus modéré que celui de janvier 2025 : aucun vérificateur on-chain n’était en cause, et l’avis ne mentionne aucun routeur gelé. Il tombe la même semaine qu’un autre débat sur le moment où publier les correctifs de sécurité : le changement de politique d’embargo de Bitcoin Core. Pour les lecteurs qui se demandent où se logent les vrais points faibles des systèmes crypto, notre guide pour savoir si une blockchain peut être piratée explique la différence entre un protocole et les logiciels qui l’entourent.

Aucune réaction de prix documentée pour le PROVE

Le jeton PROVE de Succinct, un ERC-20 à offre fixe d’un milliard d’unités, que les demandeurs utilisent pour payer les preuves et que les prouveurs mettent en jeu, n’a montré aucune réaction que Coindaro puisse rattacher à un cours horodaté. Nous ne publions donc aucun chiffre.

Succinct n’a pas encore dit si son Prover Network avait reçu une preuve malformée avant que le correctif n’y soit déployé. Les équipes qui font tourner leurs propres vérificateurs SP1 sur des preuves extérieures n’ont pas non plus confirmé de mise à jour.