
Le XRP Ledger défend son correctif d’urgence contre un bug permettant de créer une quantité illimitée de XRP
La XRP Ledger Foundation rejette les affirmations selon lesquelles son correctif de sécurité d’urgence aurait été imposé aux opérateurs du réseau.

Les développeurs du XRP Ledger ont défendu le correctif de sécurité d’urgence utilisé pour réparer une faille capable de créer des XRP au-delà de l’offre fixe du réseau. Ils ont déclaré ne pas pouvoir attendre le vote habituel des validateurs du réseau, d’une durée de deux semaines, sans exposer la faille à des attaquants.
Le correctif, publié le 25 septembre, est intervenu trois jours après un rapport de bug bounty et a pris effet immédiatement sur tout serveur qui l’installait. Il s’agissait, selon eux, du premier contournement délibéré du processus normal d’amendement depuis la création du système, il y a plus de dix ans.
« Avec un vote d’amendement normal, le correctif aurait été public pendant des semaines avant de prendre effet, ce qui aurait mis en péril la sécurité du réseau », les développeurs de XRPL ont déclaré dans une publication sur X dimanche.
Le correctif accéléré a suscité des questions sur le niveau de décentralisation de XRPL. Sur son site, XRPL affirme être une blockchain publique entièrement décentralisée — une caractérisation qui a été au cœur des arguments selon lesquels son token natif, XRP, n’est pas un titre financier.
Le correctif de sécurité de XRPL « a soulevé beaucoup de questions »
Le fondateur de Cyber Capital, Justin Bons, a déclaré jeudi que présenter XRP aux investisseurs particuliers comme un actif décentralisé constituait une « fraude pure et simple ». Il a soutenu que la version d’urgence du 25 septembre avait été distribuée uniquement sous forme de binaires, que le code source avait été temporairement retenu et que les opérateurs avaient été poussés à effectuer la mise à niveau.
Toutefois, la XRPL Foundation a déclaré que la décision de contourner le processus normal d’amendement avait été prise conjointement par la Foundation, RippleX, les développeurs principaux et les validateurs, après évaluation de la gravité du bug.
« Aucune partie ne pouvait prendre seule cette décision. Chaque validateur et opérateur de nœud choisit le logiciel qu’il exécute, et la version 341 n’est devenue obligatoire qu’à la suite d’un vote d’amendement normal, avec le soutien de plus de 80 % des validateurs pendant deux semaines. Les changements de protocole passent toujours par des amendements », a déclaré la fondation.
À lire aussi : Ledger confirme un implant matériel non autorisé, affirmant que les pertes pourraient dépasser 86 millions de dollars
XRP Kuwait, un opérateur indépendant de validateurs, a également rejeté les affirmations selon lesquelles les mises à niveau coordonnées signaleraient un contrôle centralisé.
« Nous contestons l’affirmation selon laquelle la coordination d’une mise à jour par les opérateurs constituerait, en soi, la preuve d’un contrôle centralisé », a-t-il déclaré. « La coordination n’est pas la même chose que le contrôle. Des opérateurs indépendants peuvent évaluer une situation, communiquer entre eux et parvenir à la même conclusion sans renoncer à leur indépendance. »
Le bug aurait pu créer une quantité illimitée de XRP
Selon le rapport de divulgation de vulnérabilité du projet, le bug était un dépassement d’entier dans le moteur de paiement du XRP Ledger, présent depuis 2015.
Les soldes en XRP sont stockés sous forme d’entiers de 64 bits avec un maximum fixe. Lorsqu’une somme dépassait ce maximum, le calcul revenait à un nombre plus petit au lieu d’échouer.
Un attaquant aurait pu exploiter ce problème en créant des centaines d’offres aux prix spécialement conçus, chacune demandant une très grande quantité de XRP, puis en envoyant un seul paiement qui les consommait toutes.
Le moteur aurait crédité à chaque propriétaire d’offre le montant total, mais n’aurait facturé à l’acheteur que le montant minuscule résultant du retour à la valeur initiale. La différence aurait constitué des XRP nouvellement créés et utilisables.
Selon le rapport, l’attaque nécessitait des offres construites délibérément et ne pouvait pas être déclenchée par une activité de trading normale. Les développeurs ont déclaré n’avoir trouvé aucune preuve que le problème avait été exploité sur un réseau public.

