XRP Ledger Corrige Faille Critique Et Protège Les 100 Milliards

Imaginez un instant qu’une simple transaction, soigneusement construite, puisse faire apparaître dix-huit mille milliards de jetons sur un réseau dont l’offre totale est censée être plafonnée à cent milliards. Ce scénario, digne d’un film de science-fiction, a failli devenir réalité sur le XRP Ledger. Pendant plus de dix ans, une faille née en 2015 dormait dans le moteur de paiement. Elle vient d’être neutralisée. Et le plus rassurant, c’est qu’aucun pirate ne semble avoir jamais réussi à l’exploiter sur le réseau public.

Une faille de dix ans qui menaçait l’offre totale de XRP

Le XRP Ledger repose depuis sa création sur une promesse simple et solide : il n’existera jamais plus de cent milliards de XRP. Cette limite est inscrite dans le code. Pourtant, un bug d’arithmétique integer, présent depuis 2015, ouvrait une brèche théorique capable de contourner cette règle fondamentale. Les développeurs de la XRPL Foundation et de RippleX ont officialisé la découverte le 9 octobre 2026. Leur message est clair : l’offre n’a jamais été altérée, aucune preuve d’exploitation n’a été trouvée, et le correctif a été déployé en urgence.

Le chercheur en sécurité Cayden Liao, associé à Veria AI, a mis au jour le problème le 21 septembre. Un jour plus tard, ils disposaient déjà d’une preuve de concept fonctionnelle sur un réseau de test local. Le scénario montrait qu’une transaction unique, particulièrement malicieuse, pouvait générer environ 18 000 milliards de XRP, soit près de 184 fois l’offre maximale prévue. Ce chiffre donne le vertige, mais il reste purement théorique. Sur le réseau principal, rien de tel ne s’est produit.

Aucune XRP supplémentaire n’a été créée. L’offre est restée fixée à 100 milliards depuis le lancement, et aucune transaction n’est autorisée à en produire davantage. Ce bug n’était qu’un moyen de contourner temporairement cette règle.

Fondation XRP Ledger

Comment fonctionnait réellement cette vulnérabilité

Le cœur du problème se trouvait dans le moteur de paiement du ledger, celui qui gère les transferts et les échanges sur le carnet d’ordres décentralisé intégré. Lorsqu’un paiement consommait plusieurs offres, le logiciel additionnait les montants en XRP à l’aide d’un entier 64 bits. Si la somme dépassait la capacité maximale de cet entier, le résultat « débordait » et revenait à une valeur beaucoup plus petite. Les vendeurs recevaient pourtant le montant complet de leurs offres, tandis que l’acheteur ne payait que la valeur tronquée. La différence apparaissait comme de nouveaux XRP.

Pour déclencher ce scénario, il ne suffisait pas de trader normalement. Un attaquant aurait dû créer plusieurs centaines de comptes, placer des offres à des prix très spécifiques, puis soumettre une transaction conçue pour les consommer toutes en une seule fois. Les contrôles de supply existants utilisaient la même arithmétique défaillante, ce qui les rendait inopérants. Une vérification de solde pouvait également être contournée en répartissant les jetons créés sur plusieurs portefeuilles.

La course contre la montre du correctif d’urgence

Dès le 22 septembre, les ingénieurs de RippleX ont commencé à travailler sur un correctif. Le 23, la solution était prête. Elle a été intégrée dans la version 3.4.1 de xrpld et publiée le 25 septembre. Plus de 80 % des validateurs de la liste Unique Node List par défaut avaient déjà installé la mise à jour le jour même. Un record de rapidité pour un réseau décentralisé.

Habituellement, toute modification du traitement des transactions doit passer par le système d’amendements. Il faut l’accord de plus de 80 % des validateurs de confiance pendant deux semaines consécutives. Ici, les développeurs ont choisi une autre voie. Publier un correctif via le processus normal aurait révélé la nature exacte de la faille tout en la laissant exploitable pendant la période d’approbation. Le risque était jugé trop élevé.

Le correctif ajoute des contrôles stricts : toute calcul qui dépasse la plage autorisée est purement et simplement rejeté. Le moteur de paiement renvoie désormais une erreur classique au lieu de créer des jetons. Les vérifications de supply ont également été renforcées avec un compteur plus large, capable de détecter ce type d’anomalie. D’autres calculs de solde ont été revus par précaution.

Pourquoi le déploiement a été jugé indispensable

Le code source du XRP Ledger est public. Une fois le correctif publié, n’importe qui pouvait analyser les changements et comprendre où se trouvait la faille. Attendre deux semaines aurait offert une fenêtre d’attaque dangereuse. Les équipes ont donc consulté RippleX, les opérateurs de validateurs et d’autres contributeurs. Le consensus a été clair : mieux valait forcer la mise à jour immédiate.

Ce choix n’était pas sans risque. Des validateurs tournant sur des versions différentes auraient pu interpréter une transaction malveillante de façons divergentes. Dans le pire des cas, le réseau aurait pu temporairement cesser de produire de nouveaux ledgers. Heureusement, l’adoption massive de la version 3.4.1 a évité tout incident de consensus.

Une deuxième faille neutralisée juste à temps

Le même jour, le 9 octobre, les équipes ont aussi activé un correctif concernant la fonctionnalité Batch. Celle-ci permet de regrouper jusqu’à huit transactions en une seule opération, avec différents modes d’exécution. Une erreur de validation avait été détectée : sous certaines conditions, le logiciel acceptait des noms de champs non conformes à la spécification RawTransaction. Des versions de serveurs différentes auraient pu traiter ces transactions incorrectement formatées de manières divergentes, créant un risque de désaccord de consensus.

L’amendement fixBatchV1_2 a été introduit pour imposer strictement le format officiel. Les validateurs avaient temporairement retiré leur soutien à l’activation précédente de BatchV1_1 le temps de finaliser la correction. Les deux amendements ont finalement été activés ensemble le 9 octobre, avec le soutien de 30 validateurs et seulement cinq oppositions. Aucun fonds n’a été perdu, aucune clé privée compromise, aucun échec de consensus n’est survenu.

Les serveurs qui n’ont pas encore mis à jour vers la version 3.4.1 ou supérieure sont désormais bloqués par les amendements et doivent absolument suivre pour rester synchronisés avec le réseau.

La récompense et le processus de découverte

Veria Labs a publié ses conclusions le 10 octobre. Leur système de tests automatisés avait repéré l’anomalie dès le 21 septembre. Le lendemain, la preuve de concept était opérationnelle. Cayden Liao a soumis le rapport via le programme de bug bounty officiel le 22 septembre. Initialement classée comme majeure, la vulnérabilité a été élevée au rang critique une fois les conséquences potentielles confirmées. Le 8 octobre, Veria AI a reçu la récompense maximale de 250 000 dollars.

Les équipes de sécurité ont scrutinisé l’historique du réseau public. Aucune trace d’exploitation n’a été trouvée. Les XRP créés dans le cadre des tests restaient confinés aux environnements de développement. Sur le mainnet, l’offre est restée intacte.

Les leçons pour la sécurité des blockchains

Cette affaire rappelle à quel point les bugs arithmétiques peuvent être dangereux, même dans un code mature. Un integer overflow de 2015 a survécu plus d’une décennie. Il a fallu une combinaison de tests automatisés avancés et d’expertise humaine pour le débusquer. La réaction du réseau montre aussi la maturité des équipes : capacité à déployer un correctif d’urgence sans passer par le processus normal, tout en maintenant la coordination des validateurs.

La XRPL Foundation a annoncé une nouvelle règle interne. Désormais, toute vulnérabilité précédemment signalée devra être retestée contre les candidats de release avant d’être considérée comme définitivement corrigée. Cette exigence s’appliquera aux résultats d’audits, de programmes de bug bounty, de tests assistés par intelligence artificielle et à toute autre évaluation de sécurité.

Impact sur la confiance et le marché

Au moment de la découverte, la capitalisation de XRP tournait autour de 94 milliards de dollars selon les estimations des chercheurs. Une exploitation réussie aurait pu faire s’effondrer cette valeur en quelques heures. Le fait qu’aucune trace d’attaque n’ait été trouvée rassure les détenteurs. L’offre reste strictement limitée à 100 milliards, comme promis depuis le premier jour.

Les discussions sur les réseaux sociaux ont parfois amplifié les inquiétudes. Certains ont cru, à tort, que de nouveaux XRP avaient déjà été créés. La Fondation a dû publier des clarifications précises pour tordre le cou aux rumeurs. Le message est resté constant : zéro XRP supplémentaire en circulation, correctif déployé, réseau sécurisé.

Ce que révèle cette crise sur la gouvernance du XRP Ledger

Le XRP Ledger fonctionne avec un modèle de consensus unique. Les validateurs de confiance jouent un rôle central. Leur capacité à adopter massivement une mise à jour critique en moins de 24 heures prouve que le réseau n’est pas figé. Il peut réagir vite lorsqu’une menace réelle apparaît. Cette flexibilité contraste avec certains protocoles où les mises à jour prennent des mois.

En même temps, le choix de contourner temporairement le processus d’amendement soulève des questions légitimes. Jusqu’où peut-on aller dans l’urgence sans affaiblir les principes de décentralisation ? Les équipes ont agi de manière transparente, en informant les validateurs et en publiant le code source une fois le danger écarté. Cette transparence limite les critiques.

Les prochaines étapes pour le réseau

Les développeurs continuent de renforcer les mécanismes de vérification. Les tests de régression sur les anciennes vulnérabilités deviennent systématiques. La fonctionnalité Batch, désormais sécurisée, ouvre de nouvelles possibilités pour les développeurs d’applications. Les utilisateurs, de leur côté, n’ont rien à faire de particulier, si ce n’est s’assurer que leurs portefeuilles et nœuds sont à jour lorsqu’ils en opèrent un.

Cette histoire montre aussi l’importance des programmes de bug bounty. Deux cent cinquante mille dollars pour une découverte de cette ampleur, c’est un investissement rentable. Sans le travail de Cayden Liao et de Veria AI, la faille aurait pu rester dormant encore des années.

Pourquoi l’offre de 100 milliards reste intouchable

Depuis le lancement, le code du XRP Ledger empêche toute création de nouveaux jetons au-delà de la limite initiale. Les 100 milliards ont été générés une seule fois, au moment de la création du ledger. Tout le reste n’est que circulation et redistribution. Le bug d’overflow tentait de tromper le système de comptabilité, pas de modifier la règle fondamentale. Une fois le correctif en place, même cette tromperie est devenue impossible.

Les audits réguliers, les compétitions de type Sherlock et les tests automatisés multiplient les chances de détecter les anomalies avant qu’elles ne deviennent critiques. En août, une compétition Sherlock avait déjà identifié 96 vulnérabilités valides sur des fonctionnalités proposées. La culture de la sécurité s’installe durablement.

Un réseau qui grandit en maturité

Le XRP Ledger n’est plus un projet expérimental. Il traite des millions de transactions, sert de base à des solutions de paiement et attire des développeurs du monde entier. Une faille de cette nature, découverte et corrigée sans dommage, renforce plutôt qu’elle n’affaiblit la confiance. Elle prouve que les mécanismes de défense fonctionnent et que les équipes savent réagir sous pression.

Les détenteurs peuvent continuer à suivre l’évolution du protocole sereinement. L’offre reste plafonnée. Les validateurs sont alignés. Les processus de sécurité s’améliorent. Et la transparence des équipes, même dans l’urgence, constitue un atout précieux dans un écosystème où la confiance se gagne au quotidien.

Cette affaire restera dans les annales comme un exemple de gestion de crise réussie. Une vulnérabilité majeure, un correctif rapide, une adoption massive, zéro exploitation. Le XRP Ledger sort de cet épisode plus solide qu’il n’y est entré. Et c’est probablement le meilleur signal possible pour tous ceux qui suivent de près l’avenir de cette blockchain.

Les prochains mois permettront de mesurer si d’autres améliorations de sécurité suivront. Une chose est certaine : la limite des 100 milliards de XRP n’a jamais été menacée sur le réseau public, et elle ne le sera plus grâce à ce correctif. L’histoire de cette faille de 2015 se termine ainsi, dix ans plus tard, par une victoire nette pour la sécurité du ledger.