Les développeurs du XRP Ledger ont publié un correctif de sécurité d'urgence en réponse à un bug critique qui aurait permis à des acteurs malveillants de générer du XRP supplémentaire dépensable, malgré l'offre fixe de 100 milliards de jetons du réseau.

Ce correctif a contourné le processus standard de vote des validateurs de deux semaines du registre — une décision que les développeurs ont justifiée en arguant qu'attendre aurait donné à des attaquants potentiels le temps d'exploiter la faiblesse. Le correctif a été déployé avec effet immédiat trois jours après le signalement du bug via le programme de bug bounty du réseau, qui récompense les chercheurs pour la divulgation responsable de failles de sécurité, et les développeurs ont indiqué qu'il s'agissait du premier contournement intentionnel du processus d'amendement en plus de dix ans.

Cette réponse a depuis suscité un large débat sur la manière dont le XRP Ledger gère les situations critiques, ainsi que sur son engagement en faveur de la décentralisation.

Le correctif d'urgence a contourné l'approbation des validateurs

Les amendements du protocole du XRP Ledger nécessitent normalement un consensus de plus de 80 % parmi les validateurs sur une période de deux semaines avant qu'un changement ne prenne effet — un seuil conçu pour garantir que les modifications des règles du réseau fassent l'objet d'un large accord avant leur activation. Les développeurs ont noté qu'attendre le résultat d'un vote sur le correctif de sécurité aurait pu laisser la faille ouverte à l'exploitation.

Selon un article de blog publié dimanche par les développeurs du XRP Ledger, le processus d'amendement normal aurait pu laisser le correctif exposé pendant plusieurs semaines avant l'activation de l'amendement, mettant ainsi le réseau en danger.

Si le correctif d'urgence a permis une résolution rapide, la décision de contourner le processus habituel a soulevé des questions sur le rôle joué par les équipes de développement dans la réponse aux failles de sécurité.

La Foundation précise qu'aucun XRP n'a été créé

La XRP Ledger Foundation s'est employée à dissiper la confusion après correctif :

The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let's clear them up. 1. Was any XRP created? No. XRP's supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around… — XRP Ledger Foundation (@XRPLF) October 11, 2026

Le correctif relance le débat sur la décentralisation

La réponse d'urgence a relancé la controverse sur la question de savoir si le XRP Ledger est décentralisé — une question qui a constitué l'un des principaux sujets pour déterminer le statut juridique du XRP. Le degré de contrôle qu'une équipe centrale conserve sur un réseau est un élément récurrent lorsque les régulateurs évaluent la classification d'un actif numérique.

Justin Bons, cofondateur de Cyber Capital, a vivement critiqué la mise à jour d'urgence, affirmant que le discours sur la décentralisation du XRP est trompeur :

Selling XRP to retail as "decentralized" is straight-up fraud! 🚩 XRP has been running closed-source code for the last two weeks Tomorrow, this code becomes mandatory & anyone who disagrees will get kicked off the chain! A permissioned node list means validators must obey: 🧵… pic.twitter.com/3nIcRiid8S — Justin Bons (@Justin_Bons) October 8, 2026

Dans sa publication, Bons a affirmé que le réseau faisait fonctionner du code closed-source depuis deux semaines avant une mise à jour obligatoire, et qu'une liste de nœuds autorisés exigeait de fait la conformité des validateurs.

Une autre préoccupation concerne le fait que les distributions binaires sont des fichiers exécutables : en l'absence d'une diffusion rapide du code source sous-jacent, les développeurs indépendants disposent de peu de temps pour analyser les modifications effectuées.

La XRP Ledger Foundation a expliqué que le correctif d'urgence avait été « conjointement approuvé » par la Foundation, RippleX, les développeurs et les validateurs en raison de la gravité du bug découvert dans le code. Elle a souligné que personne n'a dicté le processus décisionnel et que les opérateurs restent libres d'utiliser le logiciel de leur choix.

L'opérateur de validateurs XRP Kuwait a également soutenu le processus de correctif d'urgence, déclarant que la collaboration ne signifie pas centralisation :

Our Statement on xrpld 3.4.1 At XRP Kuwait, our journey has always been about infrastructure and purpose. Our purpose is decentralization. We pursue that purpose through independently operated infrastructure and responsible participation in the XRP Ledger. Following the… pic.twitter.com/Oo7qClwpgi — XRPKuwait (@XRPKuwait) October 11, 2026

La controverse a de nouveau jeté le doute sur la transparence et la responsabilité lors des correctifs d'urgence.

Un dépassement d'entier dans le moteur de paiement

La faille à l'origine du correctif d'urgence a été détaillée dans une divulgation de l'équipe du XRP Ledger. Selon le rapport de vulnérabilité, il s'agissait d'un dépassement d'entier dans le moteur de paiement, présent depuis 2015. Les dépassements d'entier constituent une catégorie bien établie d'erreurs logicielles dans lesquelles un calcul dépasse la valeur maximale qu'un système peut stocker et revient à un nombre bien plus petit ; dans ce cas, les calculs au-dessus de la limite maximale fixe produisaient des résultats plus petits.

Un attaquant aurait pu exploiter ce bug en envoyant des centaines d'offres demandant d'énormes montants de XRP en échange. Après le calcul erroné, l'attaquant aurait reçu ces montants tandis que l'acheteur aurait payé moins que le montant requis — pouvant ainsi générer du XRP supplémentaire dépensable.

Les règles du réseau ayant fixé l'offre de XRP à 100 milliards de jetons au lancement, toute voie permettant de produire du XRP dépensable supplémentaire aurait compromis une garantie fondamentale du registre — la règle d'offre fixe qui sous-tend la rareté de l'actif.

Cette attaque nécessitait des offres spécialement conçues et ne pouvait se produire dans le cadre normal des échanges. Le correctif a été conçu pour empêcher que cette erreur de calcul ne soit utilisée pour contourner les règles d'offre du réseau.

RippleX renforce ses efforts de sécurité

RippleX entend renforcer la sécurité du XRP Ledger grâce à la détection de vulnérabilités assistée par IA, aux tests adversariaux, à la vérification formelle et à la collaboration avec des experts en sécurité externes.

Les objectifs de ces efforts incluent la découverte de bugs dans le code, le test d'attaques possibles et l'identification des vulnérabilités avant leur exploitation. RippleX a présenté ce travail comme un effort visant à améliorer la sécurité de l'ensemble du système de code, plutôt que de simplement corriger les vulnérabilités détectées.

Concilier sécurité et transparence

Ce correctif d'urgence illustre le défi que représente le maintien de la sécurité blockchain tout en préservant la transparence décisionnelle. Bien qu'une mise en œuvre rapide soit essentielle pour se protéger contre d'éventuelles attaques, elle soulève des questions sur les processus de gouvernance et l'accès au code source.

Les développeurs ont soutenu que la vulnérabilité rendait nécessaire le contournement de la procédure standard, tandis que la Foundation a affirmé que la coordination entre les parties concernées n'affectait pas l'indépendance des validateurs.

Cet incident souligne la nécessité d'élaborer des protocoles d'urgence capables de concilier une réponse rapide avec l'ouverture du réseau.

Source : Tron Weekly