• SeedLabs a divulgué une faille de justesse (soundness) du circuit Orchard de Zcash (ZEC) le 29 mai.

• La faille pourrait permettre de générer un nombre illimité de faux ZEC indétectés.

• L’audit a utilisé Claude Opus 4.8 d’Anthropic et des agents d’audit sur mesure.

Correctif d’urgence : fermeture de la fenêtre de faux ZEC dans Orchard

Les développeurs de Zcash ont achevé un correctif d’urgence le 2 juin pour une faille dans le circuit Orchard du protocole de confidentialité qui, laissée ouverte, aurait pu permettre la frappe indétectée d’un nombre illimité de faux ZEC — l’un des risques théoriques d’approvisionnement les plus importants jamais documentés pour le protocole de confidentialité de Zcash. La découverte a été annoncée le 29 mai par SeedLabs, qui a indiqué que le défaut a été détecté lors d’un audit de sécurité assisté par l’IA plutôt que lors d’une revue manuelle classique. Cet audit a associé le modèle Claude Opus 4.8 d’Anthropic à des agents d’audit construits sur mesure, et le défaut a été classé comme un « échec de justesse » : les conditions de vérification à l’intérieur de la preuve à connaissance nulle n’étaient pas suffisamment contraignantes, ce qui signifie qu’un attaquant pouvait construire des données se faisant passer pour une preuve valide et générer des ZEC contrefaits sans déclencher les règles de validation du réseau. L’équipe a calé sa réponse sur le risque démontré. Les chercheurs de SeedLabs n’en sont pas restés au stade théorique : ils ont écrit du code d’attaque fonctionnel dans un environnement de test local et ont confirmé que des ZEC contrefaits pouvaient effectivement être produits, transformant une vulnérabilité décrite sur le papier en un scénario d’exploitation démontré. L’équipe de développement de Zcash a ensuite traité le problème comme urgent, la publication indiquant que le travail correctif était terminé d’ici le 2 juin. Orchard est le pool protégé où résident les transactions privées de Zcash ; c’est pourquoi un défaut de preuve qui s’y produit touche au cœur de la garantie d’émission de la monnaie. Pour un actif axé sur la confidentialité, l’intégrité de l’émission est la propriété la plus déterminante, et la faille l’a atteinte directement. Ce que le correctif ne règle pas, en revanche, c’est la question de l’exploitation : le chemin de génération de faux ZEC n’a été vérifié que dans un cadre de test local, et rien dans le dossier public ne confirme que la faille a déjà été exploitée sur le réseau principal. Cette distinction — vulnérabilité trouvée, exploitation démontrée localement, abus sur mainnet non confirmé — est le prisme à travers lequel toutes les informations de cette histoire doivent être lues.

Comment le défaut de solidité de l’Orchard a fonctionné

Le mécanisme en jeu est étroit, mais fondamental. Un échec de solidité dans un système de preuve à connaissance zéro signifie que les contrôles qui vérifient une preuve sont trop laxistes : une assertion qui devrait être fausse peut être « déguisée » pour avoir l’air d’avoir été prouvée. Dans le circuit Orchard de Zcash, cette laxité s’est traduite par une menace directe de création monétaire, car les notes que le pool accepte comme valides alimentent directement la comptabilité de l’offre en circulation que chaque nœud du réseau doit ré-vérifier. Des ZEC contrefaits en quantité illimitée ne seraient pas un simple dysfonctionnement de marché : ils corrompraient silencieusement la garantie d’émission qu’un protocole de couche 1 existe précisément pour imposer. Deux garde-fous structurels méritent d’être relevés. Le pool Orchard fonctionne sous un plafond d’émission, et l’introduction du pool Ironwood a été conçue de telle sorte que, même si une erreur de preuve à connaissance zéro survenait, le montant total susceptible de s’échapper de la zone protégée soit limité — la vérification de l’offre avait déjà été renforcée contre exactement ce type de défaillance. Dans l’interprétation que la divulgation elle-même propose, l’IA n’a pas « cassé » la cryptographie : elle a rapidement ciblé une erreur de logique que du code public portait depuis des années sans que des chercheurs humains ne la détectent, puis a validé que l’erreur était exploitable. L’affaire ne porte donc pas sur une cryptographie brisée, mais sur une erreur de logique manquée depuis longtemps, révélée et validée rapidement. C’est là la réelle portée de l’épisode : le code public et les systèmes d’automatisation des transactions sont désormais des cibles légitimes pour ce type d’analyse automatisée d’attaque. À l’heure où nous écrivons ces lignes, le spot ZEC est en baisse de 8,0 % sur les dernières 24 heures, et rien dans l’historique en chaîne ne relie le mouvement à la divulgation.

Ce que le correctif a changé

L’évaluation de COINOTAG est que le correctif du 2 juin a modifié la vérité technique, tandis que le registre des preuves reste volontairement mince. Il n’y a pas de hachage de transaction d’attaquant à citer, ni de montant drainé à vérifier on-chain, car les données en chaîne ne montrent aucune exploitation confirmée sur le mainnet ; la divulgation de SeedLabs elle-même sert de rapport post-mortem, en désignant comme cause racine une condition de vérification non contrainte dans le circuit Orchard, et le correctif d’urgence finalisé comme remédiation. Ce qui demeure non traité est tout aussi évident : aucune chronologie indépendante de toute tentative de contrefaçon sur le mainnet n’a été publiée. Face à ce dossier vierge, l’intérêt institutionnel n’a pourtant cessé de croître — le split ZCSH 3-pour-1 de Grayscale et la réserve de ZEC de 320 M$ de Garret Jin cadrent l’incident comme circonscrit, et les lecteurs qui évaluent leur exposition peuvent suivre notre guide pas à pas pour acheter du Zcash.