Les développeurs du XRP Ledger ont révélé une vulnérabilité critique qui aurait pu permettre à un attaquant de créer du XRP dépensable à partir de rien, en contournant les garde-fous conçus pour empêcher toute augmentation de l'offre de la cryptomonnaie.

La faille se trouvait dans le moteur de paiement du registre et a été signalée via le programme XRPL Bug Bounty le 22 septembre par Cayden Liao et Veria AI. Les ingénieurs de RippleX ont reproduit l'exploit sur un serveur autonome, confirmé que le XRP nouvellement créé pouvait être dépensé lors d'un paiement ultérieur, et élevé sa gravité de majeure à critique. Ce traitement suit la pratique standard de divulgation coordonnée : les rapports de bug bounty parviennent aux mainteneurs en privé, et les détails techniques complets ne sont publiés qu'après la sortie d'un correctif.

Selon le rapport de divulgation publié sur le blog officiel du XRPL, aucune preuve n'indique que la vulnérabilité ait été exploitée sur un réseau public du XRP Ledger. Les développeurs ont préparé un correctif en privé et publié la version 3.4.1 de xrpld le 25 septembre, deux jours après la fusion du patch dans la branche de publication d'urgence.

Un dépassement d'entier aurait pu contourner les contrôles d'offre du XRP

La faille existait dans le moteur de paiement du XRP Ledger depuis environ 2015 et impliquait une arithmétique d'entiers 64 bits non vérifiée lorsqu'un paiement consommait plusieurs offres du carnet d'ordres du réseau.

Un nombre 64 bits plafonne à environ 18,4 trillions, et les dépassements de capacité dans ce type d'arithmétique à largeur fixe constituent une classe de bugs bien connue des logiciels de registre — en 2010, un dépassement d'entier dans les contrôles de valeur de Bitcoin avait brièvement créé environ 184 milliards de BTC avant que les développeurs ne corrigent le problème en quelques heures.

Un attaquant pouvait créer des centaines de comptes et placer des offres spécialement construites vendant de petites quantités d'un autre token contre des montants extrêmement élevés de XRP. Un seul paiement consommant ces offres pouvait porter le total calculé au-delà de la valeur maximale que l'entier peut représenter. Plutôt que de rejeter la transaction, le total revenait à un petit nombre par dépassement de capacité. Chaque propriétaire d'offre pouvait néanmoins recevoir l'intégralité du montant de XRP spécifié dans son offre, tandis que l'acheteur n'était débité que de la valeur bien plus faible issue du dépassement.

L'attaque ne nécessitait que quelques centaines de XRP pour les réserves de comptes et d'offres, dont une grande partie pouvaient être récupérées par la suite, en plus des frais de transaction ordinaires.

Le contrôle intégré du XRPL, conçu pour garantir que les transactions ne peuvent pas créer de XRP, n'aurait pas stoppé l'exploit. L'invariant utilisait le même type d'arithmétique et pouvait déborder de la même manière, tandis qu'une limite de solde distincte par compte pouvait être contournée en répartissant le XRP nouvellement créé sur des centaines de comptes. Cetteilité était importante en raison du fonctionnement de l'offre de XRP : les 100 milliards de tokens ont tous été créés au lancement du registre, les frais de transaction brûlent du XRP plutôt que d'en émettre, et les contrôles d'invariants garantissent qu'aucun chemin de paiement ne peut faire augmenter le total. La faille était limitée aux transactions délibérément construites et ne pouvait pas être déclenchée par des paiements ou des activités de trading normaux.

Les validateurs sont passés à la 3.4.1 en quelques heures

Les développeurs ont choisi de déployer immédiatement le correctif du dépassement d'entier de XRP plutôt que de le soumettre au processus d'amendement normal du XRPL, qui nécessite généralement le soutien de plus de 80 % des validateurs pendant deux semaines avant l'activation d'un changement de protocole. Laisser la vulnérabilité exposée pendant toute cette période aurait créé une fenêtre durant laquelle la méthode d'attaque serait connue publiquement mais encore exploitable.

Plus de 80 % des validateurs de la liste Unique Node List par défaut étaient passés à la 3.4.1 le 25 septembre, le jour même de la sortie de la version d'urgence. L'intervalle de trois jours entre le signalement privé et l'adoption par la majorité des validateurs a démontré le fonctionnement complet du circuit de publication d'urgence du registre.

La version 3.4.1 rejette désormais les paiements lorsque le total des offres risquerait de déborder et utilise un compteur plus large pour l'invariant de création de XRP. D'autres calculs de soldes ont également été renforcés contre des défaillances arithmétiques similaires.

Cet incident fait suite à une compromission de la chaîne d'approvisionnement de xrpl.js, sans lien, découverte en 2025, qui affectait des publications malveillantes de paquets JavaScript plutôt que le protocole XRP Ledger lui-même. Le système d'amendement du XRPL est également utilisé pour des fonctionnalités plus récentes, comme le projet de XRPL Lending Protocol, où l'approbation des validateurs détermine si un nouveau comportement de transaction devient actif.

La faille de dépassement n'a pas modifié l'offre existante de XRP. Aucun XRP non autorisé n'a été identifié, et les opérateurs de serveurs doivent désormais exécuter xrpld 3.4.1 ou une version ultérieure pour rester synchronisés avec le réseau. Ce qui reste observable relève de l'opérationnel : les retardataires sur des versions antérieures passant à la 3.4.1 ou à une version ultérieure, et des propositions telles que le XRPL Lending Protocol poursuivant le circuit d'amendement standard que ce correctif a contourné.

Source : XRP Ledger Patches Decade-Old Flaw That Could Create Spendable XRP — Crypto Adventure