Un bug caché depuis 2015 dans le moteur de paiement du XRP Ledger aurait pu permettre de créer des XRP dépensables bien au-delà de l’offre fixée à 100 milliards. Le rapport de divulgation du XRP Ledger, publié le 9 octobre 2026, confirme que la faille a été corrigée dans xrpld 3.4.1 le 25 septembre. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il n’a trouvé aucune trace d’exploitation sur un réseau public. Le même rapport décrit un second bug dans la nouvelle fonction Batch, corrigé avant son activation sur le mainnet le même jour.
Le bug de dépassement : comment il a été trouvé
La faille du XRP Ledger était un dépassement d’entier dans la façon dont le moteur de paiement additionne les montants des offres. Le contrôle de sécurité censé garantir qu’aucun XRP n’est jamais créé utilisait le même calcul non vérifié : il ne voyait donc rien. Selon le rapport, l’attaque n’aurait coûté que quelques centaines de XRP de réserves récupérables, plus les frais.
Le chercheur Cayden Liao et Veria AI ont signalé le bug via le programme de bug bounty du XRPL le 22 septembre. Veria Labs affirme que son agent d’IA a repéré la faille le 21 septembre et, sur un réseau de test local, a construit une preuve de concept créant environ 18 000 milliards de XRP en une seule transaction, soit environ 184 fois l’offre totale. RippleX a reproduit le problème et relevé sa gravité de « majeure » à « critique ». Le 8 octobre, Veria a reçu la prime maximale du programme, 250 000 dollars, selon son propre récit.
Un correctif d’urgence sans vote
Les changements dans le traitement des transactions passent normalement par des « amendments », qui exigent le soutien de plus de 80 % des validateurs de confiance pendant deux semaines. Cette fois, le correctif s’est appliqué dès que chaque serveur était mis à jour. Selon le rapport, c’est la première fois qu’une modification du traitement des transactions est déployée de cette façon de manière délibérée.
Les raisons avancées par la XRPL Foundation, RippleX et les validateurs : l’attaque était peu coûteuse et ouverte à tous, les dégâts auraient été difficiles à réparer, et publier le code pendant deux semaines de vote aurait révélé la faille. Le rapport reconnaît le risque : un réseau aux versions mélangées aurait pu s’arrêter, ce que l’équipe a jugé préférable à des transactions frauduleuses. Plus de 80 % des validateurs de la liste UNL par défaut utilisaient la version 3.4.1 le jour de sa sortie.
Le 11 octobre, la Fondation a rappelé sur X que l’offre de XRP a été fixée à 100 milliards au lancement et qu’aucune transaction ne peut en créer davantage, rapporte crypto.news.
Le bug de Batch et l’activation du 9 octobre
Le second problème touchait Batch, une fonction qui regroupe jusqu’à huit transactions en une seule. Le 18 septembre, Denis Angell, de la XRPL Foundation, a constaté qu’un correctif antérieur était incomplet ; l’ingénieure de RippleX Mayukha Vadari a ensuite repéré un risque de désaccord entre versions du logiciel. Ripple et d’autres validateurs ont retiré leur vote pour l’amendment BatchV1_1 les 23 et 24 septembre afin de remettre son compteur à zéro. L’amendment fixBatchV1_2 a été activé le 9 octobre et, selon crypto.news citant XRPScan, BatchV1_1 l’a été le même jour avec 30 validateurs pour et 5 contre. Les serveurs non mis à jour sont désormais bloqués.
Un débat sur la gouvernance
Ce contournement relance la question de la décentralisation du registre. Le 13 octobre, 24/7 Wall St. citait le validateur indépendant XRP Kuwait, pour qui « coordination ne veut pas dire contrôle », tout en reconnaissant des défis de décentralisation. Bitcoin et Ethereum ont eux aussi déployé des correctifs d’urgence coordonnés, comme Bitcoin lors du bug de dépassement de 2010.
Ce que cela signifie pour les détenteurs de XRP
Aucun fonds d’utilisateur n’a été perdu, aucune clé privée exposée, et le plafond de 100 milliards de XRP tient toujours, selon la Fondation. Les détenteurs n’ont rien à faire. L’épisode rappelle que la tokenomique d’une crypto ne vaut que par le logiciel qui l’applique.
La Fondation reteste désormais chaque faille signalée sur les versions candidates avant de la considérer comme close, qu’elle vienne d’un audit, d’un bug bounty ou de tests assistés par IA. L’enjeu est réel alors que le registre cherche à séduire les institutions : des fonctions comme PermissionDelegation, qui permet aux émetteurs de stablecoins et aux dépositaires de déléguer des paiements ou des validations sans confier leurs clés, suivent le même processus d’amendment, selon CoinDesk.
Ce qu’il faut surveiller
- La vitesse à laquelle les derniers validateurs et opérateurs de nœuds passent à la version 3.4.1 ou plus.
- D’éventuelles règles formelles pour les futurs correctifs d’urgence ; la Fondation assure que le processus d’amendment ne change pas.
- Le rythme de la chasse aux bugs assistée par IA sur les autres blockchains. Pour les bases, voir notre guide Qu’est-ce qu’une blockchain.