Le 18 septembre 2026, la société d’audit Trail of Bits a publié un rapport qui a fait grincer des dents dans l’écosystème des preuves à divulgation nulle de connaissance. En auditant le zkVM Miden, porté par Polygon, ses chercheurs ont trouvé un bug capable de laisser un prouveur malveillant forger une signature Falcon, l’algorithme post-quantique candidat au standard NIST FN-DSA, et vider des comptes protégés par cette signature. Le détail qui retient l’attention du secteur : ce n’est pas un humain qui a repéré la faille en premier, mais un outil d’analyse statique construit avec Claude et Codex, en l’absence de tout outillage de développement existant pour le langage d’assemblage propriétaire de Miden.
L’affaire illustre un problème plus large que celui d’un seul projet : la classe de bugs dits “underconstrained”, où un circuit de preuve accepte une valeur fournie par le prouveur sans vérifier qu’elle respecte réellement les règles mathématiques attendues, revient avec une régularité inquiétante dans les zkVM en 2026. Miden n’est ni le premier ni sans doute le dernier projet touché. Ce qui change, c’est la vitesse à laquelle ces défauts sont désormais détectés, grâce à des outils d’audit assistés par intelligence artificielle qui commencent à s’imposer comme pratique standard chez les cabinets spécialisés.
Ce qui s’est passé le 18 septembre 2026
Trail of Bits a publié son rapport dans un billet de blog signé par le chercheur Fredrik Dahlgren, intitulé “Auditing in the age of (good enough) AI”. Le texte décrit six mois de travail sur l’outillage d’audit du zkVM Miden, dont le langage d’assemblage interne, MASM, ne disposait initialement d’aucun décompilateur ni analyseur statique. L’équipe a donc construit ces outils avec l’aide de Claude et de Codex avant même de commencer la revue de code proprement dite.
Le résultat le plus marquant de cette phase d’outillage a été la détection d’une entrée non contrainte fournie par le prouveur, susceptible de permettre la falsification d’une signature Falcon et le vol de fonds détenus par des comptes Miden protégés par une paire de clés Falcon. Trail of Bits a classé la faille en sévérité élevée. Au-delà de ce défaut précis, les mêmes outils ont signalé plus de 400 emplacements où la validation de type restait insuffisante dans la base de code auditée, un chiffre qui donne la mesure du chantier d’assainissement encore devant l’équipe Miden.
Miden zkVM : de quoi parle-t-on exactement
Miden est une machine virtuelle à divulgation nulle de connaissance associée à une infrastructure de comptes blockchain. Le principe : exécuter un programme puis produire une preuve cryptographique attestant que l’exécution s’est déroulée correctement, sans révéler l’ensemble des données privées ayant servi au calcul. Le projet est développé au sein de l’écosystème Polygon, via son programme d’incubation AggLayer Breakout, et a levé 25 millions de dollars lors d’un tour de financement annoncé en avril 2025.
Techniquement, Miden repose sur un langage d’assemblage maison baptisé MASM (Miden Assembly), qui permet d’écrire des programmes optimisés pour la génération de preuve. C’est précisément l’absence d’outillage mature autour de ce langage propriétaire qui a poussé Trail of Bits à développer ses propres analyseurs plutôt que de s’appuyer sur des outils génériques déjà disponibles pour des langages plus répandus.
Falcon et FN-DSA : la signature post-quantique en jeu
Falcon est un schéma de signature numérique fondé sur les réseaux euclidiens de type NTRU, conçu pour résister aux attaques d’un ordinateur quantique suffisamment puissant. Le NIST l’a retenu dès 2022, aux côtés de Dilithium (devenu ML-DSA) et SPHINCS+ (devenu SLH-DSA), dans le cadre de son processus de standardisation post-quantique. Sa désignation officielle prévue est FN-DSA, et le standard correspondant, FIPS 206, reste en développement : selon la documentation publique du NIST datée d’août 2026, un projet de texte est attendu fin 2026, avec une finalisation probable en 2027. Un projet de norme IETF publié en mai 2026 décrit déjà l’usage de FN-DSA dans TLS 1.3, preuve que l’algorithme dépasse largement le seul cadre des zkVM.
Falcon séduit notamment par la compacité de ses signatures et de ses clés publiques, un avantage net face à d’autres schémas post-quantiques plus volumineux. C’est cette compacité qui en fait un candidat naturel pour des environnements contraints comme un circuit de preuve, où chaque octet vérifié a un coût de calcul direct. Trail of Bits insiste sur un point : le bug découvert ne remet absolument pas en cause les fondations mathématiques de Falcon. Le problème se situe entièrement dans la façon dont Miden implémente la vérification de cette signature à l’intérieur de son circuit.
Anatomie technique de la faille : la réduction modulaire non vérifiée
Le cœur du problème se trouve dans une procédure MASM baptisée mod_12289, chargée de réduire une valeur 64 bits modulo 12289, le module utilisé par les calculs de vérification Falcon. La relation mathématique attendue est simple : un nombre x s’écrit comme 12289 fois un quotient q, plus un reste r, avec r strictement compris entre 0 et 12288.
Pour rendre la preuve plus rapide à générer, le quotient et le reste sont fournis directement par le prouveur sous forme de valeurs d’assistance (“advice values”), plutôt que recalculés par le circuit lui-même. Le circuit doit alors vérifier non seulement que la relation arithmétique est respectée, mais aussi que ces deux valeurs ont bien le type et la plage attendus. Trail of Bits a constaté que le quotient était correctement validé comme un nombre 64 bits représenté par deux blocs de 32 bits, mais que le reste, lui, n’était jamais validé de la même façon avant d’être transmis à une instruction 32 bits, u32overflowing_sub.
// Schéma illustratif simplifié du défaut de contrainte
// (pseudocode, ne reflète pas le code MASM réel ligne à ligne)
fn mod_12289(x: u64, quotient_hint: u64, remainder_hint: u64) -> u64 {
assert_valid_u64(quotient_hint); // contrôle correct des 2 limbes 32 bits
// remainder_hint : AUCUNE vérification de plage avant usage
let check = quotient_hint * 12289 + remainder_hint;
u32overflowing_sub(x, check); // opération 32 bits sur une valeur non bornée
remainder_hint // peut être renvoyé sans être le vrai reste
}En choisissant un quotient et un reste savamment construits, un prouveur malveillant pouvait satisfaire les contraintes existantes tout en faisant renvoyer par la procédure une valeur qui n’était pas le véritable reste de la division. Cette valeur incorrecte se propageait ensuite dans la vérification Falcon, avec pour conséquence qu’une signature forgée pouvait apparaître valide aux yeux du circuit. C’est exactement le type de défaut que Trail of Bits résume ainsi : “these tools found real security issues, like an unvalidated prover-supplied input that would let a malicious prover forge Falcon signatures and steal funds from Miden account holders”, peut-on lire sur le blog de Trail of Bits.
Comment l’IA a débusqué un bug que personne n’avait vu
Le point qui distingue cet audit des précédents tient à sa méthode. Trail of Bits explique avoir utilisé Claude et Codex non pas pour écrire du code de production, mais pour bâtir en amont un décompilateur et un moteur d’analyse statique pour MASM, un langage qui n’en possédait aucun. Sur le réseau social X, l’équipe a résumé la démarche en ces termes : “We audited parts of @0xMiden’s zkVM, written in a custom assembly language called MASM. MASM originally had no developer tooling, so we used Claude and Codex to build a decompiler and static-analysis engine. It flagged a signature-forgery bug that could’ve cost millions”, a publié Trail of Bits.
La formulation retenue par les auditeurs eux-mêmes mérite d’être citée intégralement, car elle capture bien la philosophie de ce nouveau mode d’audit : “Before code review even starts, agents let us build custom tooling and formal models”, précise le billet de blog. Autrement dit, l’IA n’a pas remplacé le jugement humain sur la vulnérabilité elle-même : elle a servi à construire, en un temps largement réduit, l’infrastructure d’analyse qui a ensuite permis aux auditeurs de repérer le défaut de contrainte dans mod_12289.
Trail of Bits résume l’impact potentiel avec une formule sans détour : “A malicious prover could exploit this to forge Falcon signatures and drain any Miden account controlled by a Falcon key pair”, indique le rapport. Aucune preuve d’exploitation en conditions réelles n’a été rapportée : la faille a été trouvée pendant la phase d’audit, avant tout déploiement en production visé par un attaquant identifié.
Sévérité, statut du correctif et zones d’ombre
Trail of Bits qualifie la vulnérabilité de sévérité élevée mais ne publie, à ce stade, ni score CVSS ni numéro de CVE officiel. Aucun commit de correction ni version patchée de Miden n’a été communiqué publiquement au moment de la divulgation du rapport le 18 septembre 2026, ce dernier ayant été mis à jour le 22 septembre. Il s’agit donc d’une découverte remontée par le canal d’audit classique, sans confirmation publique à ce jour d’un identifiant CVE ni d’une date de correctif précise, un flou qui n’est pas rare pour ce type de rapport d’audit privé livré directement à l’équipe du projet concerné.
Aucun montant précis de fonds effectivement exposés n’a été communiqué. Trail of Bits évoque un préjudice qui “could’ve cost millions” si la faille avait été exploitée, une estimation de l’ampleur du risque et non la preuve d’une perte réelle. Il n’existe pas non plus, dans les sources publiques disponibles, de chiffre de valeur totale bloquée (TVL) spécifique à Miden qui permettrait de quantifier l’exposition théorique des comptes contrôlés par des clés Falcon.
Une même famille de bugs frappe d’autres zkVM en 2026
Le cas Miden n’est pas isolé. L’année 2026 a déjà vu plusieurs incidents similaires dans d’autres machines virtuelles à preuve, tous rattachés à la même famille de défaut : une contrainte insuffisante sur une valeur fournie par le prouveur. Chez OpenVM, la bibliothèque openvm-pairing a été touchée par la faille référencée CVE-2026-46669, patchée dans la version 1.6.0. La fonction en cause, try_honest_pairing_check, omettait de vérifier qu’un facteur d’échelle appartenait bien au sous-corps attendu de F_p12, ce qui permettait à un prouveur malveillant de forger n’importe quelle égalité de pairing.
Cette faille OpenVM a elle aussi été repérée par un auditeur automatisé, cette fois l’outil “zkao” de zkSecurity, décrit comme trouvant “a critical soundness bug: the pairing check accepted a prover-supplied witness without proper subfield checking, which lets a malicious prover forge any pairing equality”, selon le billet publié par zkSecurity. Chez RISC Zero, deux bugs de solidité ont fait l’objet de récompenses de bug bounty, l’un à 50 000 dollars et l’autre à 1 000 dollars, d’après un article de recherche académique publié sur arXiv. Chez Jolt, un défaut critique dans le vérificateur transparent a permis, temporairement, qu’une preuve falsifiée pour une exécution invalide soit acceptée comme valide, avant d’être corrigé rapidement après signalement.
Tableau comparatif : incidents de solidité dans les zkVM en 2026
| Projet zkVM | Nature du défaut | Détecté par | Sévérité | Statut |
|---|---|---|---|---|
| Miden (Polygon) | Reste non contraint dans la vérification Falcon (mod_12289) | Trail of Bits, outillage Claude + Codex | Élevée | Signalé, correctif public non confirmé |
| OpenVM | Facteur d’échelle non vérifié dans le pairing check (openvm-pairing) | zkSecurity, outil IA “zkao” | Critique (CVE-2026-46669) | Corrigé en version 1.6.0 |
| RISC Zero | Deux bugs de solidité distincts (détail non public) | Recherche académique / bug bounty | Non communiquée (primes de 50 000 $ et 1 000 $) | Récompensé, corrigé |
| Jolt | Vérificateur transparent acceptant une preuve invalide | Signalement externe | Critique | Corrigé rapidement après divulgation |
Falcon face à ML-DSA et SLH-DSA : où en est l’adoption
La faille Miden prend un relief particulier au vu de la place que Falcon commence à occuper en dehors même de la blockchain. Le schéma est cité comme candidat sérieux dans les feuilles de route post-quantiques d’Ethereum, fait l’objet d’un projet de norme IETF pour son usage en TLS 1.3, et d’un autre pour son encodage JOSE et COSE. Chacun de ces usages potentiels repose sur la même hypothèse : que les implémentations de vérification Falcon respectent scrupuleusement les invariants numériques du schéma. Le bug Miden démontre qu’un module de vérification peut sembler correct, passer une revue superficielle, et pourtant laisser passer une falsification si une seule valeur fournie par un tiers n’est pas bornée comme il se doit.
| Contexte d’usage de Falcon / FN-DSA | Statut fin 2026 | Organisme |
|---|---|---|
| Standard NIST FIPS 206 | En développement, projet de texte attendu fin 2026 | NIST |
| Usage en TLS 1.3 | Internet-Draft publié en mai 2026 | IETF |
| Encodage JOSE/COSE | Internet-Draft publié en mars 2026 | IETF |
| Vérification dans un zkVM (Miden) | Faille de vérification signalée en septembre 2026 | Trail of Bits / Polygon Miden |
| Feuille de route Ethereum post-quantique | Candidat évoqué, non déployé en production | Fondation Ethereum |
Contexte historique : une classe de bugs aussi vieille que les smart contracts
Sur le fond, ce type d’incident rappelle une leçon déjà apprise, à ses dépens, par l’écosystème des contrats intelligents. Le piratage du DAO en 2016 avait mis en lumière la réentrance comme classe de vulnérabilité systémique dans les contrats Ethereum, avant que des années d’audits et d’outils spécialisés ne finissent par la rendre rare dans du code sérieusement revu. Les zkVM traversent aujourd’hui une phase comparable avec les bugs de solidité (“soundness bugs”) : un circuit qui prouve correctement l’exécution d’un programme, mais dont les contraintes laissent filtrer des cas limites que le prouveur peut exploiter à son avantage.
La différence notable en 2026, c’est la vitesse de détection. Les langages d’assemblage propriétaires comme MASM, ou les circuits en Rust des zkVM plus récents, ne bénéficient pas encore de la maturité outillée dont profite Solidity depuis près d’une décennie. C’est cette lacune que les auditeurs comblent désormais en construisant, à la volée et avec l’aide de modèles de langage, des outils d’analyse sur mesure plutôt que d’attendre qu’un écosystème d’outils générique émerge naturellement.
Impact sur le marché et la confiance dans les zkVM
Pour Polygon et l’écosystème Miden, l’épisode est à double tranchant. D’un côté, la découverte publique d’un bug de cette gravité, avant tout déploiement massif de fonds réels, illustre le rôle protecteur d’un audit indépendant mené en amont. De l’autre, elle rappelle aux investisseurs institutionnels, déjà prudents face à la jeunesse technologique des zkVM, que la promesse de sécurité cryptographique d’une preuve à divulgation nulle de connaissance ne vaut que ce que vaut son implémentation la plus fragile.
Le tour de financement de 25 millions de dollars levé par Miden en avril 2025, dans le cadre du programme AggLayer Breakout de Polygon, avait positionné le projet comme l’un des zkVM les plus suivis de l’écosystème. Un tel incident, même corrigé avant exploitation, pèse mécaniquement sur le calendrier d’adoption par des applications qui géreraient de la valeur réelle : plus une équipe manipule des fonds via des clés post-quantiques comme Falcon, plus la moindre incertitude sur la robustesse de la couche de vérification retarde le passage en production à grande échelle.
Ce que cela change pour les développeurs de zkVM
Repenser la confiance accordée aux valeurs d’assistance
Le principe même des “advice values”, ces données que le prouveur fournit au circuit pour accélérer un calcul, reste indispensable à la performance des zkVM modernes. Mais l’affaire Miden rappelle une règle simple que documentent désormais plusieurs cabinets d’audit spécialisés en cryptographie : chaque valeur d’assistance doit être contrainte explicitement dans le circuit, sans exception, y compris quand elle semble n’intervenir que dans un calcul intermédiaire jugé secondaire. Le reste d’une division modulaire paraissait, sur le papier, un détail d’implémentation, mais il s’est révélé être la clé de voûte de toute la vérification Falcon.
Vers des outils d’audit génériques pour les langages zkVM propriétaires
La méthode employée par Trail of Bits pour MASM, et par zkSecurity avec son outil “zkao” pour OpenVM, dessine une tendance de fond : plutôt que d’attendre l’apparition d’un outillage mature pour chaque langage d’assemblage propriétaire, les auditeurs génèrent désormais eux-mêmes décompilateurs et analyseurs statiques à l’aide de modèles de langage, projet par projet. Cette approche réduit le délai entre la publication d’un nouveau zkVM et la capacité de la communauté de sécurité à l’auditer sérieusement.
Réactions de la communauté zero-knowledge et post-quantique
Trail of Bits a choisi de présenter l’incident non pas comme un simple rapport de vulnérabilité, mais comme une démonstration de méthode, résumée par cette phrase du billet de blog : “Here’s how six months of building with AI agents helped us find real issues in our Miden zkVM audit”, peut-on lire sur la page d’accueil du blog de Trail of Bits. Ce cadrage a suscité un débat immédiat dans la communauté zero-knowledge : faut-il désormais considérer l’assistance par IA comme un prérequis pour tout audit sérieux de zkVM, au même titre que la vérification formelle ou le fuzzing ?
Le parallèle avec OpenVM, audité quelques semaines plus tôt par une méthode similaire chez zkSecurity, renforce cette lecture : deux cabinets distincts, deux outils différents, mais un même constat sur des projets différents. La convergence de ces deux résultats interroge autant qu’elle rassure : elle prouve que ces outils fonctionnent, mais elle suggère aussi que la classe de bugs “underconstrained” reste largement sous-détectée dans les circuits déjà en production.
Perspectives : ce qu’il faut surveiller dans les prochains mois
- Les audits de zkVM vont de plus en plus systématiquement s’appuyer sur des outils d’IA générative pour construire décompilateurs et modèles formels avant même la revue de code, suivant l’exemple donné par Trail of Bits sur Miden et par zkSecurity sur OpenVM.
- D’autres implémentations de vérification Falcon, en dehors de Miden, notamment dans des circuits zkVM concurrents ou dans des piles TLS expérimentales, devraient faire l’objet de réaudits ciblés sur la même classe de défaut de contrainte.
- Le NIST pourrait être incité à publier plus rapidement des vecteurs de test de référence pour FIPS 206, afin de réduire le risque que chaque implémentation reproduise indépendamment ce type d’erreur.
- Les projets zkVM qui prévoient de gérer des fonds réels vont probablement renforcer leurs programmes de bug bounty spécifiquement centrés sur les bugs de solidité, à l’image de ce que RISC Zero pratique déjà.
- Un mouvement de mutualisation des outils d’analyse statique pour langages d’assemblage zkVM propriétaires (MASM, Cairo, et équivalents) est probable, afin d’éviter que chaque projet ne reparte de zéro sur son outillage de sécurité.
Questions fréquentes
Qu’est-ce que Miden zkVM exactement ?
Miden est une machine virtuelle à divulgation nulle de connaissance développée dans l’écosystème Polygon, via le programme d’incubation AggLayer Breakout. Elle exécute des programmes et produit des preuves cryptographiques attestant que l’exécution s’est déroulée correctement, sans révéler les données privées utilisées.
Qu’est-ce que la signature Falcon et pourquoi est-elle importante ?
Falcon est un schéma de signature numérique post-quantique fondé sur les réseaux euclidiens, retenu par le NIST en 2022 et en cours de standardisation sous le nom FN-DSA (FIPS 206). Elle est appréciée pour la compacité de ses signatures, un atout pour les environnements contraints comme les circuits de preuve.
La faille a-t-elle été exploitée avant sa découverte ?
Non. Selon les informations publiées par Trail of Bits, le défaut a été trouvé lors d’un audit de sécurité, avant tout déploiement massif visé par un attaquant. Aucune preuve d’exploitation en conditions réelles n’a été rapportée.
Le bug remet-il en cause la sécurité mathématique de Falcon ?
Non. Trail of Bits précise explicitement que le problème se situe dans l’implémentation de la vérification Falcon au sein du circuit Miden, et non dans les fondations cryptographiques du schéma Falcon lui-même.
Qu’est-ce qu’un bug “underconstrained” dans un circuit zero-knowledge ?
C’est un défaut où le circuit de preuve n’impose pas suffisamment de contraintes sur une valeur fournie par le prouveur, ce qui permet à un prouveur malveillant de faire accepter un résultat incorrect tout en produisant une preuve techniquement valide selon les règles définies.
Quel rôle a joué l’intelligence artificielle dans la découverte de cette faille ?
Trail of Bits a utilisé Claude et Codex pour construire un décompilateur et un moteur d’analyse statique pour MASM, le langage d’assemblage de Miden, qui n’en possédait aucun. Ce sont ces outils qui ont signalé le défaut de contrainte à l’origine du bug de falsification de signature.
D’autres zkVM comme SP1, RISC Zero ou zkSync sont-ils concernés par le même type de bug ?
Des incidents comparables, liés à la même famille de défaut de contrainte, ont déjà touché OpenVM (CVE-2026-46669) et RISC Zero en 2026. Ils ne concernent pas nécessairement le même code, mais relèvent tous du même schéma d’erreur : une valeur fournie par le prouveur insuffisamment vérifiée par le circuit.
Mes fonds sont-ils en danger si j’utilise une application construite sur Miden ?
À ce jour, aucune preuve publique d’exploitation n’a été rapportée et la faille a été détectée avant tout incident confirmé. Il reste toutefois recommandé de suivre les communications officielles de l’équipe Miden concernant un éventuel correctif et sa date de déploiement.
