Bitcoin.com News
Propulsé par

Une faille de 10 ans du XRP Ledger aurait permis de créer du XRP de rien

Le XRP Ledger a discrètement corrigé une faille datant de 2015 dans son moteur de paiement, qui aurait pu permettre à un pirate de créer des XRP utilisables au-delà de l'offre fixe du réseau, en n'utilisant que quelques centaines de XRP de ses réserves.

ÉCRIT PAR
PARTAGER
Une faille de 10 ans du XRP Ledger aurait permis de créer du XRP de rien

Points clés

  • Cayden Liao et Veria AI ont initialement signalé le bug de débordement du XRPL via le programme de prime aux bogues le 22 septembre 2026.
  • RippleX a classé cette faille comme critique, et plus de 80 % des validateurs UNL par défaut ont appliqué le correctif xrpld 3.4.1 dès le 25 septembre.
  • La divulgation concernant l’XRPL du 9 octobre n’a révélé aucune exploitation, l’amendement fixBatchV1_2 ayant été mis en ligne le jour même.

Qu’est-ce qui ne fonctionnait pas réellement ?

Le problème se trouvait dans le code chargé de régler les paiements au sein de l’échange décentralisé (DEX) intégré au XRP Ledger. Selon le rapport officiel de divulgation de la vulnérabilité publié hier, lorsqu’un seul paiement faisait appel à de nombreuses offres, le moteur additionnait les montants à l’aide d’une arithmétique 64 bits non vérifiée.

En poussant cette somme suffisamment haut, elle « bouclait », ce qui correspond à un débordement d’entier. Un nombre gigantesque devenait alors un petit nombre et les vendeurs de l’autre côté de la transaction étaient payés intégralement, tandis que l’acheteur n’était débité que du minuscule total « bouclé ». La différence correspondait à du XRP qui n’avait jamais existé auparavant.

Le registre effectue bien un contrôle de sécurité, appelé « invariante », censé confirmer qu’aucun XRP n’est jamais créé. Ce contrôle utilisait le même calcul non vérifié ; il était donc incapable de détecter précisément la défaillance qu’il était censé repérer. Le rapport attribue cette faille au moteur de paiement actuel, qui a été développé en 2015.

Quel aurait été le coût d’une attaque ?

Selon le rapport, le coût s’élevait à quelques centaines de XRP bloqués en réserve, qui sont restitués une fois les objets supprimés, auxquels s’ajoutent les frais de transaction habituels. Un attaquant aurait dû passer des centaines d’offres délibérément mal évaluées, puis acheminer un paiement à travers celles-ci.

C’est le gain potentiel qui était le plus effrayant : RippleX a qualifié ce bug de critique, car une transaction validée unique aurait pu créer des XRP dépensables dépassant l’offre totale. Tout le principe du XRP repose sur un plafond fixe de 100 milliards de jetons ; une création silencieuse de jetons aurait donc porté atteinte à la promesse fondamentale de cet actif. C’est pourquoi des publications telles que celle de Whale Insider ont présenté ce bug comme un défaut qui aurait pu faire apparaître des « milliards » de XRP.

Qui l’a découvert et en combien de temps a-t-il été corrigé ?

Le déroulement des événements a été assez rapide et s’est déroulé comme suit :

  • 22 septembre : Cayden Liao et Veria AI ont signalé leur découverte via le programme de prime aux bogues XRPL, en lui attribuant le niveau de gravité « Major ».
  • 23 septembre : RippleX a reproduit le bug, a relevé son niveau à « critique » et le correctif a été intégré.
  • 25 septembre : la version 3.4.1 de Xrpld a été déployée, et plus de 80 % des validateurs de la liste de nœuds uniques (UNL) par défaut l'utilisaient ce jour-là.
  • 9 octobre : divulgation publique.

Le correctif n’a pas fait l’objet du vote d’amendement habituel, mais a été intégré directement sous forme de modification du code dans la version 3.4.1 et est entré en vigueur à mesure que chaque serveur était mis à jour. Le code source n’a été publié qu’après le déploiement, une procédure standard visant à éviter de fournir une « carte » aux attaquants. Le compte XRPL Operations a depuis fait de la version 3.4.1 la version minimale requise, en ajoutant :

Nous n’avons trouvé aucune preuve indiquant que cette faille ait été exploitée sur un réseau public.

Un deuxième bug, de gravité moindre, a été corrigé dans la même version. Il concernait la manière dont les transactions par lots sont regroupées, et sa correction s’inscrit dans le cadre de l’amendement fixBatchV1_2, qui a été mis en ligne sur le Mainnet le 9 octobre parallèlement à BatchV1_1. Le rapport indique qu’aucun fonds n’a été perdu à cause de ce bug non plus.

Cette révélation est survenue au cours d’une semaine difficile pour la sécurité des cryptomonnaies, les pertes liées aux appareils Ledger, rapportées par Bitcoin.com News, ayant atteint un montant estimé à 93,4 millions de dollars. Enfin, Evernorth, soutenu par Ripple, s’apprête à faire son entrée au Nasdaq sous le symbole XRPN lundi, avec environ 473 millions de XRP dans ses comptes. Le XRP s’est également développé dans le domaine de la finance décentralisée (DeFi), Firelight ayant récemment activé la protection par coffre-fort sur le réseau.

Un tribunal malaisien a accordé à Ripple une sûreté sur la participation de 60 % détenue par Seamless dans Tranglo afin de recouvrer 24 millions de dollars correspondant à des factures impayées en XRP liées à son service ODL.

Lire: Litige Ripple sur XRP: 24 M$ menacent 400 M$ dans Tranglo

Cet article a été traduit de l'anglais à l'aide de l'IA. La version originale en anglais fait foi ; les traductions automatiques peuvent contenir des inexactitudes, en particulier dans la terminologie juridique et réglementaire.