Une faille du XRP Ledger découverte par l’IA ouvrait une voie de création de 18 450 milliards de XRP

Veria AI a découvert une faille du XRP Ledger qui, selon les chercheurs, aurait pu créer 18 450 milliards de XRP, malgré l’offre fixe de 100 milliards de la cryptomonnaie.

L’exploit combinait une erreur de calcul dans le moteur de paiements du registre avec un contrôle de sécurité reproduisant la même erreur. Un paiement spécialement conçu pouvait créditer des centaines de comptes vendeurs tout en ne facturant presque rien à l’acheteur.

RippleX a reproduit l’exploit, l’a classé comme critique et a publié xrpld 3.4.1 le 25 septembre 2026. La divulgation officielle indique que les enquêteurs n’ont trouvé aucune preuve que quiconque ait exploité cette vulnérabilité sur un réseau public.

Cette distinction est importante. Il ne s’agissait pas d’un vol de 18 000 milliards de XRP, et ce montant théorique n’aurait pas eu de valeur de marché réalisable. Il s’agissait d’une voie crédible pour enfreindre la règle fondamentale de l’offre de XRP.

L’incident met également à l’épreuve une promesse plus large entourant la sécurité assistée par l’IA. Un agent IA semble avoir découvert un défaut vieux de dix ans que les audits et les tests conventionnels n’avaient pas détecté. Pourtant, des chercheurs humains ont encore dû valider le résultat, coordonner une correction confidentielle et convaincre les validateurs de procéder à la mise à niveau.

La faille du XRP Ledger a été corrigée avant sa divulgation publique

L’histoire immédiate est celle d’une réponse d’urgence réussie face à une vulnérabilité restée exploitable pendant près d’une décennie.

Veria Labs indique avoir dirigé son agent de sécurité vers rippled, le logiciel serveur open source utilisé par le XRP Ledger. L’entreprise affirme que son système a identifié le code vulnérable, développé un exploit fonctionnel et l’a testé sur un réseau local.

La reconstitution technique de l’entreprise date la découverte initiale par l’IA au 21 septembre. Le système a produit une preuve de concept fonctionnelle le lendemain, selon Veria.

Le chercheur Cayden Liao a examiné le résultat et l’a signalé via le programme de bug bounty de XRPL le 22 septembre. Les ingénieurs de RippleX ont confirmé le problème le jour même après l’avoir reproduit sur un serveur autonome et au sein de leur cadre de test.

La confirmation allait au-delà de la démonstration d’une anomalie comptable. RippleX a établi que les XRP nouvellement créés pouvaient être transférés lors d’un paiement ultérieur, rendant le résultat effectivement dépensable.

Les développeurs ont fusionné un correctif le 23 septembre et publié rippled 3.4.1 deux jours plus tard. La divulgation publique a attendu le 9 octobre, après avoir laissé aux opérateurs le temps d’installer le logiciel corrigé.

Veria affirme que plus de 80 % des validateurs exécutaient cette version le 25 septembre. Le compte officiel de XRPL indique de même que plus de 80 % des validateurs de la liste par défaut Unique Node List avaient procédé à la mise à niveau ce jour-là.

Une Unique Node List, ou UNL, identifie les validateurs auxquels un serveur fait confiance pour évaluer le consensus. L’adoption rapide parmi ces validateurs a réduit le danger posé par les anciens nœuds continuant d’accepter la transaction vulnérable.

La réponse s’est écartée du processus habituel de modification du comportement des transactions. XRPL introduit généralement les changements sensibles au consensus au moyen d’amendements, que les validateurs examinent avant leur activation.

Les développeurs ont plutôt intégré directement la correction du dépassement dans la version du serveur. Ils ont temporairement retenu les modifications de code source concernées, limitant la possibilité pour des attaquants de rétroconcevoir la vulnérabilité avant qu’un nombre suffisant de validateurs ait effectué la mise à niveau.

Ce choix a concentré la confiance entre les mains des mainteneurs et des opérateurs de validateurs pendant une courte période. Il a également empêché qu’un processus public d’amendement ne devienne un manuel d’instructions pour un bug d’inflation immédiatement exploitable.

Le rapport officiel indique que la XRPL Foundation, RippleX et les validateurs participants ont estimé que la mise à niveau confidentielle était plus sûre que de laisser un exploit ouvert disponible pendant des semaines. Le correctif est devenu public après que le réseau a franchi le seuil de sécurité nécessaire.

Veria a reçu la récompense critique maximale de 250 000 $ le 8 octobre. Ce montant reflète le niveau de gravité, mais ne doit pas être confondu avec une perte mesurée.

Aucun XRP non autorisé n’a été découvert, aucune perte de fonds d’utilisateurs n’a été signalée et aucune transaction du registre public n’a été liée à l’exploit. L’urgence concernait ce que le code acceptait, et non des dommages déjà observés.

Ce résultat rend l’événement facile à minimiser. Toutefois, l’absence d’exploitation ne réduit pas l’importance d’un défaut capable d’invalider l’hypothèse d’offre fixe de l’actif.

Comment la faille du XRP Ledger pouvait créer des XRP dépensables

L’exploit fonctionnait parce que deux garde-fous monétaires effectuaient des calculs vulnérables presque de la même manière.

Le premier défaut apparaissait dans la gestion par le moteur de paiements des offres provenant de l’échange décentralisé intégré au XRP Ledger. Les offres permettent à des comptes d’échanger des XRP ou des actifs émis via les carnets d’ordres du registre.

Un attaquant commencerait par créer de nombreux comptes sous son contrôle et émettre un jeton sans valeur. Ces comptes placeraient ensuite des centaines d’offres artificielles réclamant des montants de XRP extrêmement élevés pour ce jeton.

La preuve de concept de Veria utilisait 256 offres. Chacune demandait un peu plus de 2^56 drops, un drop représentant un millionième de XRP.

L’attaquant soumettrait ensuite un paiement conçu pour consommer l’ensemble des offres. Le moteur de paiements devait additionner les montants de XRP associés à chaque offre avant de facturer l’acheteur.

Ce total dépassait la capacité de l’entier non signé de 64 bits utilisé pour le calcul. Un dépassement d’entier se produit lorsqu’une valeur franchit son maximum autorisé et revient à un nombre beaucoup plus petit.

Ici, l’agrégat dépassait 2^64 drops. Les propriétaires individuels des offres pouvaient recevoir leurs montants complets, tandis que le dépassement faisait apparaître la facturation globale de l’acheteur comme étant de seulement 256 drops.

C’était plus grave qu’un cours d’échange incorrect. Les soldes crédités représentaient des XRP qu’aucun compte source n’avait fournis.

Le résultat représentait environ 18 446 744 073 709 XRP, avant prise en compte du débit de la source et des frais de transaction. Veria résume la quantité utilisable à environ 18 450 milliards de XRP répartis entre 256 comptes.

Cette répartition était essentielle. XRPL applique une limite à la quantité de XRP détenue par un compte unique, mais chaque bénéficiaire restait sous ce plafond.

L’attaque contournait donc une protection en répartissant les nouveaux XRP sur de nombreux comptes. Les chercheurs indiquent que les XRP crédités pouvaient ensuite circuler par des paiements ordinaires ou atteindre des plateformes d’échange.

XRPL disposait également d’un invariant censé empêcher précisément ce résultat. Un invariant est une condition de sécurité post-transaction qui doit rester vraie avant que le registre n’accepte une modification.

L’invariant XRPNotCreated calculait la variation nette du solde en XRP pour l’ensemble de la transaction. Il aurait dû rejeter tout résultat montrant que la transaction créait davantage de XRP qu’elle n’en détruisait via les frais.

Toutefois, ce calcul utilisait une arithmétique vulnérable au même dépassement. La variation nette revenait à une valeur ressemblant à une destruction ordinaire de frais, ce qui permettait à la transaction d’être acceptée.

En pratique, le moteur de paiements évaluait mal ce que l’acheteur devait. Le contrôle de l’offre, apparemment indépendant, répétait ensuite l’échec mathématique et approuvait le faux résultat.

Cette défaillance commune constitue la leçon essentielle de conception. Un contrôle de secours offre une protection limitée lorsqu’il repose sur le même type de données, le même comportement arithmétique ou la même hypothèse que le composant qu’il surveille.

L’attaque ne pouvait pas être déclenchée accidentellement par un trader ordinaire. Elle exigeait des centaines d’offres délibérément tarifées et un paiement conçu pour les consommer ensemble.

Elle exigeait également quelques centaines de XRP pour les réserves de comptes et d’offres, ainsi que des frais de transaction. Le rapport sur la vulnérabilité estime ce besoin à quelques centaines de XRP, la plupart des réserves étant récupérables par la suite.

L’attaquant n’avait pas besoin de contrôler un validateur. Une fois préparée et signée, la transaction d’exploit aurait rejoint le réseau comme un paiement par ailleurs ordinaire.

L’attaque était également répétable. D’autres groupes de comptes contrôlés pouvaient recréer cette configuration, permettant de produire un autre lot de 18 450 milliards de XRP.

La correction a introduit des contrôles de dépassement dans le code d’addition des offres. Un total dépassant la plage autorisée échoue désormais au lieu de revenir à une petite facture.

Les développeurs ont également élargi l’accumulateur utilisé par l’invariant d’offre. D’autres parcours d’addition de soldes ont reçu un renforcement associé afin de réduire le risque d’une nouvelle défaillance arithmétique commune.

Une offre fixe rendait les dommages potentiels systémiques

Le véritable risque n’était pas la valeur nominale impossible de 18 450 milliards de XRP, mais la crédibilité de chaque unité légitime déjà en circulation.

XRP a commencé avec une offre totale de 100 milliards de jetons. Il n’est pas produit par minage ou staking, et les frais de transaction ordinaires en détruisent de petites quantités au fil du temps.

Cette conception donne aux utilisateurs une attente monétaire simple. Les transactions peuvent redistribuer des XRP, mais elles ne devraient jamais augmenter l’offre totale.

La faille du XRP Ledger enfreignait cette règle au niveau comptable. Si elle avait été exploitée, elle aurait pu placer des XRP nouvellement créés dans des comptes ordinaires sans marquer visiblement ces soldes comme différents.

Le résultat signalé de 18 450 milliards représentait environ 184 fois l’offre initiale. Toutefois, multiplier cette quantité par le prix de marché produit une mesure trompeuse des dommages économiques.

Un attaquant n’aurait pas pu vendre des milliers de milliards de XRP au prix antérieur à l’attaque. La liquidité disponible aurait disparu, les plateformes d’échange auraient pu suspendre les transactions, et le prix aurait réagi bien avant que la plupart des jetons n’atteignent un acheteur.

La référence plus pertinente était la capitalisation boursière d’environ 94 milliards de dollars de XRP lorsque Veria a évalué la vulnérabilité. Elle représentait la valeur dont l’hypothèse sous-jacente de rareté subissait une pression.

Même ce chiffre ne constitue pas une estimation garantie des pertes. La capitalisation boursière n’équivaut pas à des liquidités stockées dans un réseau, et les différents détenteurs auraient connu des conséquences différentes.

Le risque systémique venait de la confiance. Une émission non autorisée pouvait diluer les détenteurs existants, submerger la liquidité des plateformes d’échange, perturber les applications et soulever des questions sur les garanties comptables du registre.

Les institutions auraient également fait face à une incertitude opérationnelle. Les plateformes d’échange auraient pu devoir identifier les dépôts affectés, les prestataires de paiement auraient pu suspendre le règlement, et les dépositaires auraient pu restreindre les retraits pendant une enquête.

Ces réponses auraient pu nuire aux utilisateurs légitimes même si un attaquant n’avait capturé qu’une faible partie du montant mis en avant. Une défaillance de l’offre se propage au-delà des comptes directement impliqués.

Cela aide à expliquer la publication confidentielle. Les mainteneurs protégeaient à la fois le protocole et la fenêtre de réponse disponible pour les plateformes d’échange, les validateurs et les fournisseurs d’infrastructure.

La faille existait probablement depuis l’écriture du moteur de paiements en 2015. Une seconde faiblesse dans l’invariant d’offre datait de 2017, selon l’analyse de Veria.

Cette chronologie met à mal l’idée selon laquelle la longévité suffit à prouver la sécurité. Un logiciel peut traiter des milliards de transactions tout en conservant une voie d’exploitation que l’activité normale n’exerce jamais.

Ripple a déclaré en mars que XRPL avait traité plus de 100 millions de registres et trois milliards de transactions depuis 2012. Ces chiffres démontrent une utilisation étendue, mais ils ne couvrent pas tous les états arithmétiques possibles.

C’est l’entrée rare qui comptait ici. Les paiements normaux ne pouvaient pas approcher la valeur nécessaire au dépassement, car l’offre légitime de XRP était bien inférieure à ce seuil.

Un attaquant devait fabriquer des valeurs extrêmes dans le carnet d’ordres à travers de nombreuses offres. Des tests classiques fondés sur un comportement économique plausible n’auraient peut-être jamais exploré cette combinaison.

Les audits n’ont pas non plus éliminé le risque. Veria affirme que la base de code a fait l’objet de plus d’une douzaine d’audits ou de concours d’audit depuis 2024, parallèlement à un programme de primes établi.

Cela ne prouve pas que les audits aient été négligents. Les audits sont soumis à des contraintes de temps, de périmètre et d’incitation, tandis que des interactions rares peuvent rester cachées entre des composants distincts.

La leçon est plus restreinte et plus utile. Un code financier mature a besoin de tests qui mettent à l’épreuve les limites des machines, et pas uniquement de scénarios ressemblant au comportement habituel des utilisateurs.

L’IA de sécurité a trouvé le bug, mais les humains l’ont contenu

La découverte soutient l’usage de l’IA pour la sécurité, tandis que la réponse montre pourquoi l’analyse autonome n’est qu’une couche de la défense d’un protocole.

Veria attribue à son agent de sécurité IA à la fois la découverte et la construction de l’exploit. L’entreprise affirme que le système a analysé rippled, relié les deux faiblesses arithmétiques et construit une preuve de concept locale fonctionnelle.

Ce récit est significatif, car la vulnérabilité exigeait un raisonnement entre plusieurs composants. Découvrir le seul dépassement de capacité dans les paiements n’aurait pas garanti le succès si l’invariant d’approvisionnement avait rejeté la transaction.

L’agent aurait reconnu que l’invariant reproduisait le dépassement de capacité. Il a ensuite conçu une entrée déclenchant les deux défaillances au sein d’une même transaction.

Les affirmations de Veria bénéficient d’un soutien externe substantiel. RippleX a reproduit l’exploit de manière indépendante, confirmé que les XRP créés pouvaient être dépensés et rehaussé le signalement de majeur à critique.

La divulgation officielle de XRPL ne fournit pas d’évaluation complète de l’autonomie de l’agent. Elle confirme le signalement et le résultat technique, mais ne mesure pas indépendamment la part de direction humaine ayant conduit à la découverte.

Cette lacune importe pour l’évaluation des produits de sécurité IA. Une découverte réussie peut associer, dans des proportions variables, analyse automatisée du code, prompts rédigés par des humains, examen itératif et validation manuelle d’exploits.

L’incident apporte néanmoins davantage de preuves qu’un score de benchmark. Il a conduit à une vulnérabilité critique confirmée, à une version de production et au versement d’une prime maximale.

Ripple avait déjà annoncé un programme plus large de sécurité par IA en mars 2026. Ce programme associait des tests assistés par IA à une équipe rouge dédiée, au fuzzing, à la vérification formelle et à un examen plus strict des amendements.

Les tests de fuzzing soumettent un logiciel à des entrées inattendues ou malformées afin de révéler des plantages et des états invalides. La vérification formelle emploie des techniques mathématiques pour déterminer si un logiciel satisfait des propriétés définies.

Ces méthodes répondent à des modes de défaillance différents. L’IA peut inspecter le code et proposer des chemins d’attaque, les fuzzers peuvent explorer les espaces d’entrée, et les méthodes formelles peuvent tester des invariants critiques.

Les ingénieurs humains décident toujours si une découverte est exploitable, si son impact est réel et comment la corriger sans perturber le consensus. Ils gèrent également la divulgation auprès d’une base décentralisée d’opérateurs.

La réponse du XRP Ledger illustre clairement cette répartition. L’agent a trouvé le chemin, Liao l’a examiné et RippleX a reproduit l’exploit dans des environnements contrôlés.

Les développeurs ont ensuite modifié plusieurs chemins arithmétiques. Les opérateurs de validateurs ont installé la version, tandis que les mainteneurs surveillaient l’adoption avant de divulguer les détails.

Aucun participant ne contrôlait seul l’ensemble du résultat. Le système dépendait de la coopération entre une entreprise privée de sécurité, des développeurs open source, une fondation, RippleX et des opérateurs indépendants.

Cette coordination est une force, car plusieurs parties ont examiné la découverte. Elle constitue aussi une dépendance de gouvernance qui mérite d’être examinée.

Le correctif d’urgence a été distribué avant que l’explication au niveau du code source ne devienne publique. Les validateurs ont dû décider s’ils faisaient confiance à la version sans bénéficier de la transparence habituelle des changements de routine.

L’alternative comportait son propre danger. Publier les mécanismes exacts du dépassement de capacité avant une adoption large aurait offert aux attaquants un chemin opérationnel contre chaque validateur non corrigé.

C’est le compromis central, et non une simple opposition entre IA et audit humain. Une découverte plus rapide accroît la valeur de procédures de réponse rapides, fiables et soigneusement gouvernées.

Les mêmes outils qui aident les défenseurs à inspecter du code ancien peuvent aussi aider les attaquants à rechercher des erreurs équivalentes. L’ingénieure de RippleX Mayukha Vadari a averti dans la divulgation que l’IA modifie les délais entourant la découverte et l’exploitation des vulnérabilités.

Un programme mature a donc besoin de plus que de meilleurs scanners. Il lui faut une divulgation confidentielle répétée, des critères de gravité clairs, des canaux de communication avec les validateurs et une capacité de mise à niveau mesurable.

Ce que la faille du XRP Ledger ne prouve pas

L’exploit confirmé était grave, mais plusieurs interprétations médiatiques vont au-delà des éléments disponibles.

Premièrement, aucune preuve n’indique que 18,45 billions de XRP aient été inscrits dans un registre public. Les chercheurs ont créé cette sortie dans un environnement contrôlé afin de valider la vulnérabilité.

Deuxièmement, aucune source n’a établi que des attaquants connaissaient ce chemin avant le signalement de Veria. L’ancienneté du code vulnérable décrit une durée d’exposition, et non une connaissance adversaire confirmée.

Troisièmement, les 94 milliards de dollars prétendument à risque ne doivent pas être considérés comme une prévision de pertes. Ce chiffre décrit le marché dont la garantie de rareté risquait d’être endommagée.

Quatrièmement, l’incident n’établit pas qu’un système d’IA a réalisé de façon indépendante chaque étape de la recherche. Veria a fourni le récit le plus détaillé du rôle de l’agent, tandis que des humains ont assuré l’examen et la divulgation.

Ces réserves ne rendent pas la découverte théorique au sens péjoratif du terme. RippleX a reproduit la transaction et confirmé qu’un paiement ultérieur pouvait dépenser les nouveaux XRP.

La vulnérabilité a également atteint le code de production. Il ne s’agissait pas d’une fonctionnalité proposée et interceptée avant son activation, contrairement à un problème distinct de transaction Batch corrigé dans la même version 3.4.1.

Associer ces incidents peut prêter à confusion. La faille Batch concernait la validation d’enveloppes et un possible désaccord entre versions de serveur.

Cet amendement Batch n’avait pas été activé sur le réseau principal. Les validateurs ont géré sa correction via un vote d’amendement, et la version corrigée a été activée le 9 octobre.

Le dépassement de capacité XRP a suivi une voie différente. Il affectait le comportement existant du moteur de paiement et a été corrigé immédiatement lorsque les nœuds ont installé la version 3.4.1.

Le registre de version contient donc deux correctifs de sécurité aux historiques d’exposition et de gouvernance différents. Seul le dépassement de capacité dans les paiements a créé la voie de création monétaire alléguée.

Une autre incertitude concerne la détection historique. XRPL affirme n’avoir trouvé aucune preuve d’exploitation sur les réseaux publics, mais les lecteurs doivent distinguer « aucune preuve » d’une preuve absolue d’absence.

Un attaquant exploitant cette faille créerait des variations inhabituelles de soldes et une activité atypique dans le carnet d’ordres. Ces traces devraient faciliter l’analyse rétrospective, notamment compte tenu de la nécessité de centaines d’offres artificielles.

Toutefois, la divulgation publique ne présente ni méthodologie médico-légale complète ni recherche dans l’historique du registre auditée de manière indépendante. Sa conclusion reste la constatation rapportée par les mainteneurs.

La mise à niveau rapide du réseau mérite également un examen continu. Une adoption de plus de 80 % parmi les validateurs du default UNL a réduit l’exposition immédiate, mais les autres nœuds et fournisseurs d’infrastructure suivent des calendriers différents.

Un logiciel ancien ne peut pas devenir sûr grâce à une déclaration de divulgation. Les opérateurs exécutant rippled 3.4.0 ou une version antérieure demeurent responsables de la mise à niveau.

Enfin, cet événement ne montre pas que l’IA a rendu l’audit des blockchains complet. Il montre qu’un processus assisté par IA a trouvé un bug important dans une base de code mature.

Le prochain test est la reproductibilité. Les équipes de sécurité ont besoin de preuves que des systèmes similaires trouvent des vulnérabilités diverses et auparavant inconnues sans submerger les mainteneurs de signalements peu solides.

Elles doivent aussi évaluer l’usage adversarial. Une découverte défensive plus rapide n’a de valeur que si la correction et le déploiement peuvent devancer la reproduction malveillante.

Trois signaux montreront si le modèle de sécurité s’est amélioré

La prochaine phase devrait être évaluée à travers le code, le comportement des validateurs et des résultats de sécurité reproductibles de manière indépendante.

Le premier signal est l’adoption continue de rippled 3.4.1 ou d’une version ultérieure. La correction du dépassement de capacité critique s’applique lors de l’installation du logiciel ; les nœuds obsolètes restent donc le risque évitable le plus clair.

La télémétrie publique des validateurs devrait montrer la disparition des versions vulnérables des rôles de consensus significatifs. Une adoption lente affaiblirait l’affirmation selon laquelle XRPL peut se coordonner dans des conditions urgentes.

Le deuxième signal est un examen technique des invariants monétaires au-delà de ce correctif précis. Le contrôle d’approvisionnement défaillant partageait un comportement arithmétique avec le composant qu’il était censé surveiller.

Les développeurs devraient tester d’autres totaux, conversions et chemins de solde avec des accumulateurs plus larges et une gestion explicite des dépassements de capacité. Un examen indépendant renforcerait davantage la confiance qu’une nouvelle assurance générale.

Le troisième signal est la preuve que les tests assistés par IA produisent des découvertes reproductibles dans le cadre d’une divulgation responsable. Des vulnérabilités confirmées, de faibles taux de faux positifs et une supervision humaine claire étayeraient l’affirmation plus large de Veria.

Un flux de signalements sensationnalistes mais non vérifiés l’affaiblirait. Il en irait de même pour des découvertes exigeant une reconstruction humaine importante et non divulguée avant de devenir exploitables.

L’incident modifie déjà le niveau de référence en matière de sécurité. Une longue période d’exploitation, des audits antérieurs et une conception à offre décroissante n’ont pas empêché une erreur de limite machine de menacer la règle monétaire fondamentale de XRP.

Dans le même temps, la réponse a fonctionné avant l’apparition d’un exploit public. Les chercheurs ont signalé le problème, les ingénieurs l’ont reproduit et les validateurs ont installé une correction d’urgence en quelques jours.

Les développeurs et les opérateurs d’infrastructure devraient maintenant se demander si leurs propres contrôles de sécurité échouent différemment des systèmes qu’ils supervisent. Une hypothèse dupliquée ne constitue pas une véritable défense en profondeur.

Pour les lecteurs suivant la faille du XRP Ledger, l’action la plus utile consiste à surveiller l’adoption des versions, les examens de code indépendants et les futures divulgations de primes. Ces signaux révéleront s’il s’agissait d’une correction isolée ou du début d’un modèle de sécurité plus solide.