Une IA a trouvé dans Zcash un bug caché pendant 4 ans

Une intelligence artificielle a découvert en deux jours une faille cryptographique que quatre ans de révision humaine n'avaient pas détectée dans le circuit de confidentialité de Zcash. Le 29 mai 2026, l'ingénieur en sécurité Taylor Hornby, mandaté par Shielded Labs, a découvert une vulnérabilité de soundness (solidité : la garantie qu'une preuve cryptographique n'est acceptée que si l'affirmation qu'elle démontre est réellement vraie) dans le circuit Orchard, le cœur du pool blindé de Zcash. La faille permettait de frapper de faux ZEC de manière illimitée et indétectable au sein du pool privé, sans laisser de trace sur la chaîne. Hornby a crédité Claude Opus 4.8, le modèle d'Anthropic publié la veille, comme l'outil lui ayant permis d'écrire l'exploit fonctionnel. Le bug était présent depuis mai 2022. Cet article n'est pas un simple rapport de piratage : c'est l'explication de pourquoi un circuit de connaissance zéro (zero-knowledge) peut cacher une faille qui ne brise rien de visible — pas de panne, pas de transaction suspecte, aucun moyen de savoir a posteriori si elle a été exploitée — et pourquoi cela est particulièrement dévastateur pour une monnaie dont l'unique produit est la confidentialité. Nous allons reconstruire la chronologie exacte, expliquer ce qu'une preuve ZK garantit ou non, et décortiquer la question qu'aucun correctif ne peut clore : le supply (la masse monétaire totale) de ZEC est-il intact ?

Qu'est-ce qui a échoué exactement dans le circuit Orchard ?

Orchard est le pool blindé de dernière génération de Zcash, activé lors de la mise à jour réseau NU5 en mai 2022. Lorsque quelqu'un détient du ZEC « dans l'ombre » — dans le pool privé, sans que les adresses ni les montants ne soient visibles —, ces fonds résident au sein d'Orchard. Pour que cette dissimulation soit sécurisée, chaque transaction privée est accompagnée d'une preuve de connaissance zéro : une démonstration mathématique que l'opération est valide (l'émetteur possède les fonds, on ne crée pas d'argent à partir de rien, les comptes tombent juste) sans révéler aucune donnée concrète. Le réseau ne voit pas les montants ; il vérifie seulement la preuve et, si elle passe, accepte la transaction.

Le problème résidait dans la construction de cette preuve. Selon l'avis technique de Shielded Labs, le circuit Orchard contenait un élément sous-contraint (under-constrained) : une opération interne de multiplication sur une courbe elliptique qui acceptait des entrées fausses comme valides. En d'autres termes, il était possible d'introduire des valeurs arbitraires et fausses dans cette multiplication et, malgré tout, de faire en sorte que la vérification les valide.

La correction finale a été minuscule — une restriction manquante dans la logique du circuit —, et cette disproportion est précisément ce qui est inquiétant : un détail infime séparait un système de confidentialité considéré comme robuste d'une machine à falsifier de l'argent. La faille ne se trouvait pas dans le logiciel du nœud, ni dans les portefeuilles, ni dans la cryptographie sous-jacente de Zcash. Elle se trouvait dans l'implémentation du circuit, dans la bibliothèque de composants qui traduit les règles comptables de Zcash en restrictions mathématiques vérifiables.

Que signifie une faille de « soundness » par rapport à un piratage classique ?

Il convient de distinguer deux propriétés que toute preuve de connaissance zéro doit respecter, car la différence est au cœur de cette histoire.

Imaginez le contrôle d'accès d'un bâtiment avec un tourniquet (le cylindre rotatif qui ne laisse passer qu'une personne à la fois avec une carte valide). La première propriété attendue est que celui qui possède une carte valide puisse toujours entrer : c'est ce qu'on appelle, en cryptographie ZK, la completeness (complétude). La seconde, plus importante, est que celui qui n'a pas de carte valide ne puisse jamais entrer, même en fabriquant une contrefaçon assez bonne pour tromper le lecteur : cette garantie est appelée soundness (solidité).

Une faille de soundness est précisément cela : le tourniquet laisse passer quelqu'un avec une fausse carte. La preuve mathématique accepte comme vraie une affirmation qui est mensongère. Dans le cas d'Orchard, l'affirmation fausse était « je possède ce ZEC et je ne le crée pas à partir de rien ». Avec le circuit corrompu, un attaquant pouvait construire une preuve affirmant « ces fonds sont légitimes » alors qu'il venait de les inventer, et le réseau l'acceptait sans objection.

La conséquence pratique est ce qui sépare ce cas d'un piratage conventionnel. Dans un exploit normal — un drainage de contrat, un pont compromis — il y a une trace : des transactions déplaçant des fonds vers une adresse, un pic anormal, un solde qui se vide. Ici, rien de tel. Comme la falsification se produit à l'intérieur du pool blindé, où par conception les montants et les adresses ne sont pas visibles, le faux ZEC est indiscernable du vrai. Il n'y a pas de crash, pas d'alerte, pas de transaction marquée comme suspecte. Le système fonctionne tout aussi bien en fabriquant de la fausse monnaie qu'en déplaçant de l'argent réel, car sa fonction est de ne rien divulguer sur ce qui se passe à l'intérieur.

Pourquoi une IA l'a-t-elle trouvé alors que quatre ans de révision humaine ont échoué ?

Taylor Hornby n'est pas un nouveau venu : c'est un ingénieur en sécurité chevronné, recruté par Shielded Labs en avril 2026 pour auditer le protocole. Le 28 mai, Anthropic a publié Claude Opus 4.8. Le lendemain, Hornby l'a mis au travail sur le circuit Orchard avec un harnais de prompts et d'outils sur mesure — un ensemble d'instructions et d'utilitaires enchaînés pour diriger le modèle —, en le concentrant sur une révision ciblée de la logique du circuit. En moins de 48 heures, le système a signalé l'incohérence dans la multiplication sur courbe elliptique. Hornby a ensuite écrit un exploit complet qui, dans un environnement de test local, a généré du faux ZEC de manière illimitée et indétectable, confirmant que la faille était réelle et exploitable.

Pourquoi ne l'a-t-on pas vue plus tôt ? Un circuit ZK n'est pas un code lisible comme un programme normal. C'est un système de restrictions algébriques : des milliers d'équations qui, ensemble, doivent fermer la porte à tout état invalide. Vérifier qu'aucune restriction ne manque est radicalement plus difficile que de vérifier que celles qui existent fonctionnent. Le code « fait ce qu'il faut » dans tous les cas de test ; la faille réside dans le cas que personne n'a écrit, dans la restriction que personne n'a ajoutée. C'est une erreur par omission, non par commission, et les erreurs par omission sont presque invisibles à la lecture humaine, aux tests et aux audits classiques, qui tendent à vérifier que ce qui est écrit fonctionne, et non que tout ce qui devrait être écrit l'est effectivement.

C'est là qu'un modèle de langage doté d'une capacité de raisonnement suffisante sur les mathématiques et le code apporte quelque chose que l'œil humain ne peut égaler : la patience de parcourir de manière exhaustive l'espace de ce qui devrait être restreint et ne l'est pas. Ce n'est pas de la magie et cela ne remplace pas l'ingénieur — c'est Hornby qui a dirigé la recherche et écrit l'exploit —, mais cela marque un précédent : la première vulnérabilité cryptographique critique de cette classe, en production depuis des années, publiquement attribuée à l'utilisation d'une IA de pointe.

Comment s'est déroulée la réponse d'urgence de 50 heures ?

Ce qui a suivi la divulgation privée a été une opération chirurgicale en deux temps, exécutée en un peu plus de deux jours, et conçue avec un soin inhabituel pour ne pas trahir la faille pendant sa correction.

Le problème de corriger en public un bug de cette gravité est une question de transparence : le code de Zcash est public. Si les développeurs avaient directement mis en ligne la correction du circuit, n'importe qui ayant accès au commit aurait pu lire le correctif, en déduire la vulnérabilité qu'il comblait et l'exploiter sur les réseaux non encore mis à jour. Un correctif, pour un attaquant attentif, est une carte de la faille.

La solution a été de dissocier le confinement et la correction en deux mouvements :

1. Confinement (soft fork). Le 2 juin vers 02:00 UTC, au bloc 3.363.426, un soft fork d'urgence (Zebra 4.5.3) a été activé, rejetant simplement toute transaction touchant à Orchard. Le pool blindé a été gelé : personne ne pouvait exploiter ce qui ne pouvait plus être utilisé, et le correctif ne révélait pas ce qui était réparé car, techniquement, il ne réparait rien — il fermait simplement la porte.
2. Correction (hard fork). Un jour plus tard, le 3 juin vers 04:05 UTC, au bloc 3.364.600, le hard fork NU6.2 (Zebra 5.0.0) a réactivé Orchard avec le circuit corrigé.

Le hard fork était inévitable pour une raison technique : corriger un bug dans un circuit de connaissance zéro oblige à mettre à jour la clé de vérification fixée (le paramètre cryptographique contre lequel le réseau valide chaque preuve). Ce paramètre est ancré dans les règles de consensus, et sa modification ne peut se faire par un simple correctif logiciel du nœud — elle nécessite que tout le réseau bascule simultanément vers un nouvel ensemble de règles. D'où la mise à jour du réseau.

Qu'est-ce qu'une preuve ZK garantit et qu'est-ce qu'elle ne garantit jamais ?

L'incident expose un malentendu répandu sur les preuves de connaissance zéro : qu'une preuve « mathématiquement vérifiée » équivaut à une vérité absolue. Ce n'est pas le cas. Une preuve ZK ne garantit que ce que les restrictions du circuit imposent. Si le circuit est bien construit, la preuve est aussi fiable que les mathématiques sous-jacentes. S'il manque une restriction, la preuve certifie avec une conviction totale un mensonge, et elle le fait avec la même fermeté qu'elle certifierait une vérité. La cryptographie n'est pas brisée ; c'est le modèle de ce qui est démontré qui l'est.

Le tableau suivant sépare ce que le système continuait de garantir de ce qu'il a cessé de garantir tant que la faille était active.

La colonne de droite représente la véritable étendue des dégâts. Et la dernière ligne définit la question ouverte de toute cette affaire.

Pourquoi personne ne peut savoir si le supply de ZEC est intact ?

Zcash dispose d'un mécanisme appelé turnstile (tourniquet), conçu précisément pour surveiller la comptabilité entre les pools. Chaque fois que la valeur franchit la frontière entre le supply transparent (visible) et le supply blindé (caché), le turnstile vérifie qu'il ne sort pas plus que ce qui est entré globalement. C'est un filet de sécurité qui détecte une inflation massive : si quelqu'un tentait de sortir du pool privé plus de ZEC qu'il ne devrait mathématiquement en exister, le turnstile le bloquerait à la frontière.

Voici la nuance que presque toute la couverture médiatique a simplifiée. Le turnstile surveille le transit entre les pools, pas ce qui se passe à l'intérieur de l'un d'eux. Tant que le ZEC falsifié restait à l'intérieur d'Orchard, sans franchir la sortie, il était invisible pour le tourniquet. Et si un attaquant l'avait sorti petit à petit, mélangé à des fonds légitimes et en dessous de tout seuil suspect, il n'existe aucun moyen cryptographique de distinguer cette sortie d'un retrait normal.

C'est pourquoi deux affirmations qui semblent contradictoires coexistent. D'une part, le turnstile confirme qu'aucune création de valeur non autorisée n'a été détectée au niveau global, et il n'y a aucune preuve d'exploitation sur le mainnet. D'autre part, Shielded Labs reconnaît explicitement que, en raison des propriétés de confidentialité d'Orchard, il n'existe aucun moyen définitif — par la seule cryptographie — de déterminer si l'exploitation a eu lieu. Les deux sont vrais simultanément : il n'y a pas de preuve d'exploitation, et il ne peut y avoir de preuve d'absence d'exploitation. La confidentialité qui protège l'utilisateur est la même qui empêche d'auditer la falsification.

Pour une monnaie axée sur la confidentialité, c'est existentiel d'une manière qui ne le serait pas pour Bitcoin ou Ethereum, où n'importe qui peut calculer le supply en regardant la chaîne. Tout le produit de Zcash repose sur la confiance que ce que l'on ne voit pas est exact. Lorsque cette confiance ne peut plus être vérifiée cryptographiquement, elle devient un acte de foi.

Comment le marché a-t-il réagi et que propose Shielded Labs maintenant ?

La réaction du marché a été immédiate. Après la divulgation publique du 5 juin, le ZEC s'est effondré : CoinDesk a rapporté une chute d'environ 38 % en 24 heures, avec un plus bas proche de 442 $. Sur une fenêtre de 48 heures, d'autres sources ont situé la correction à près de 50 %. La fourchette exacte dépend de l'échelle de temps et de l'exchange, mais l'ordre de grandeur — une perte d'un tiers à la moitié de la valeur en deux jours — est cohérent dans toute la couverture.

La véritable inconnue n'est pas le prix, mais le plan de fond. Comme on ne peut pas démontrer cryptographiquement que le supply est propre, Shielded Labs a proposé une mise à jour réseau plus ambitieuse qu'un simple correctif : créer un nouveau pool blindé et forcer une comptabilité par turnstile sur tous les fonds migrant depuis l'ancien Orchard. En pratique, cela reviendrait à obliger chaque ZEC blindé à « passer par la douane » lors de son transfert vers le nouveau pool, où son existence pourra être confrontée au supply auditable. C'est la seule voie pour reconstruire, de manière vérifiable, une vérité comptable que la faille a suspendue. C'est aussi une opération délicate qui rouvre des débats de gouvernance sur qui décide et comment s'exécute un changement d'une telle ampleur sur un réseau décentralisé.

Le schéma rappelle d'autres incidents récents où le problème n'était pas la cryptographie en soi, mais l'écart entre ce que le code devrait garantir et ce qu'il garantissait réellement en production. Nous l'avons analysé dans le cas du correctif fantôme de Gnosis Pay, où une réparation existait dans le dépôt mais n'est jamais parvenue au contrat déployé. La leçon partagée est inconfortable : « audité » et « vérifié » ne signifient pas « correct ».

Quelles leçons pour la confidentialité ZK et pour le rôle de l'IA en sécurité ?

La première leçon est sobre : les preuves de connaissance zéro ne sont aussi fortes que la justesse de leurs circuits, et vérifier cette justesse est l'un des problèmes ouverts les plus difficiles de la cryptographie appliquée. Chaque protocole qui empile confidentialité ou scalabilité sur des circuits ZK — et ils sont de plus en plus nombreux, des stablecoins privés aux rollups — hérite de cette surface de risque. La confidentialité on-chain n'est pas un interrupteur que l'on actionne ; c'est une propriété qui dépend du fait que des milliers de restrictions algébriques soient toutes présentes et correctement positionnées.

La deuxième leçon pointe vers l'avenir immédiat. Qu'une IA de pointe ait détecté en 48 heures ce que des années de révision n'ont pas vu est à double tranchant. D'un côté, c'est un outil défensif surpuissant : les équipes qui intègrent des modèles capables de raisonner sur des circuits dans leurs audits trouveront des failles plus tôt. De l'autre, ce même pouvoir est à la disposition de l'attaquant, et tous ceux qui trouveront un bug de soundness ne le divulgueront pas de manière responsable comme l'a fait Hornby. La fenêtre entre « un nouveau modèle peut trouver cela » et « quelqu'un le trouve avec de mauvaises intentions » se réduit à chaque génération.

Pour l'écosystème de la confidentialité — des monnaies comme Zcash aux nouveaux stablecoins de confidentialité sur réseaux ZK et aux feuilles de route de confidentialité institutionnelle sur Ethereum (2025-2029) —, l'épisode fixe un standard : auditer les circuits ZK avec l'assistance de l'IA ne sera plus optionnel. L'affaire s'est close sans pertes vérifiées et avec une réponse technique exemplaire en termes de rapidité, mais elle laisse une question qu'aucun hard fork ne résout : dans un système conçu pour ne rien dire, comment prouver que rien n'a été brisé ?

Sources et liens : Zcash Community Forum — The Orchard Counterfeiting Vulnerability · Zcash Foundation — Zebra 4.5.3 et 5.0.0 · CoinDesk · Decrypt · BitMEX Blog