XRP : une faille corrigée pouvait créer 18 450 milliards de tokens

Une faille du XRP Ledger pouvait créer des XRP que le protocole interdit normalement d’émettre. Corrigée dans xrpld 3.4.1, elle a été dévoilée le 9 octobre. Les équipes du réseau indiquent n’avoir trouvé aucune preuve d’exploitation sur un réseau public.

Le risque portait sur l’intégrité de la monnaie, pas simplement sur un portefeuille. L’incident pose aussi une question de gouvernance : comment déployer une correction urgente sans laisser une vulnérabilité exploitable pendant le vote des validateurs ?

En bref

• Veria Labs décrit une démonstration créant environ 18 450 milliards de XRP, en environnement de test.
• Le correctif a été distribué avant la publication des détails ; aucune exploitation publique n’a été identifiée par les équipes.
• Les opérateurs doivent utiliser xrpld 3.4.1 ou une version ultérieure compatible.

XRP : un chiffre spectaculaire, pas un vol constaté

La maintenance du protocole était déjà au centre de la proposition de retirer le bridge natif XLS-38 du XRP Ledger. Cette fois, l’enjeu concerne directement la possibilité de fabriquer l’actif natif. Il ne s’agit pas d’un token tiers imitant son nom.

Dans son analyse technique publiée le 10 octobre, Veria Labs chiffre sa démonstration à environ 18 446,7 milliards de XRP. Rapporté aux 100 milliards d’unités initiales, cela représente approximativement 184 fois l’offre de départ. C’est une comparaison de quantités, pas une estimation de revenus réalisables.

Veria présente également une capitalisation de 94 milliards de dollars comme exposition potentielle. Ce montant n’est pas une perte constatée. Une émission frauduleuse aussi massive aurait pu dégrader la confiance et le prix ; rien ne permet d’affirmer que ces unités auraient trouvé des acheteurs au cours antérieur.

Le rapport officiel de divulgation distingue bien la capacité reproduite en test d’une exploitation publique. L’absence de preuve rapportée ne constitue toutefois pas une garantie absolue sur tout l’historique du réseau.

Deux contrôles aveuglés par le même calcul

Veria situe le problème dans l’addition des montants lors du traitement d’ordres. Un entier informatique possède une capacité limitée : si le programme ne contrôle pas le dépassement, son résultat peut devenir incorrect. Ici, le total débité pouvait ne plus correspondre aux sommes créditées.

La documentation des invariants de XRPL décrit pourtant un second contrôle, exécuté avant l’enregistrement des changements. Il doit notamment empêcher une transaction de créer des XRP et vérifier les limites des soldes.

Deux protections n’offrent pas nécessairement deux défenses indépendantes. D’après l’analyse de Veria, le contrôle global utilisait lui aussi un compteur susceptible de déborder. Il pouvait donc valider un résultat comptable déjà faussé. L’enseignement dépasse ce protocole : tester une règle métier ne suffit pas si sa vérification partage la faiblesse du calcul initial.

C’est une distinction utile avec les permissions de création de tokens dans un smart contract. Une émission autorisée par un administrateur et une émission issue d’un bug du moteur natif posent deux problèmes différents.

Pourquoi l’urgence a bousculé le vote

Le processus normal d’amendement exige le soutien de plus de 80 % des validateurs de confiance pendant deux semaines. Son intérêt est concret : faire appliquer une nouvelle règle au même point de l’historique, plutôt que laisser plusieurs versions traiter différemment une transaction.

Cette coordination éclaire le débat entre contrôle opérationnel et décentralisation. La rapidité d’une décision ne dit pas, à elle seule, qui peut imposer durablement les règles d’un réseau.

Pour la faille d’émission, les équipes ont choisi une application immédiate après mise à jour. Elles expliquent qu’attendre aurait exposé publiquement le bug avant sa neutralisation. Ce choix créait un risque temporaire de désaccord entre versions, assumé face au danger d’une émission frauduleuse.

Le sujet rejoint, sans confondre les architectures, les discussions sur les interventions d’urgence après un piratage. La question n’est pas seulement de pouvoir agir vite, mais d’expliquer quelle exception est utilisée et pourquoi.

Deux corrections, deux calendriers

L’annonce du 25 septembre présentait la version 3.4.1 comme une publication d’urgence. Elle détaillait déjà le renforcement des calculs arithmétiques, mais retenait temporairement le code source pour des raisons de sécurité.

Le rapport d’octobre traite aussi un autre défaut, lié à l’encapsulation des transactions Batch. Celui-ci n’a pas affecté de fonds sur le mainnet avant sa correction. Il a suivi un calendrier distinct : l’amendement fixBatchV1_2 est entré en vigueur le 9 octobre.

Il faut donc éviter de fusionner les deux événements. La correction du moteur de paiement s’appliquait avec la mise à jour du serveur ; l’autre changement dépendait de l’activation d’un amendement.

Ce que les opérateurs doivent vérifier

La publication actuelle sur GitHub confirme que les anciennes versions ne comprenant pas le nouvel amendement sont désormais bloquées pour suivre le réseau. L’action attendue concerne les opérateurs de serveurs : mettre à jour leur logiciel, puis vérifier sa synchronisation et la continuité du service.

La documentation rappelle qu’un serveur bloqué par un amendement ne peut plus déterminer correctement la validité des registres ou participer au consensus. Une application peut donc posséder une interface fonctionnelle tout en dépendant d’un serveur devenu inadapté.

Pour le lecteur, la vérification importante est différente : distinguer un correctif effectivement distribué, une démonstration de recherche et un incident financier constaté. Notre analyse s’appuie sur les documents des mainteneurs et des chercheurs ; nous n’avons pas exécuté indépendamment leur démonstration.

La suite se mesure à la qualité du déploiement et des contrôles, pas au seul chiffre de XRP théoriquement créables. Une règle d’offre limitée n’est fiable que si le logiciel qui la fait respecter, ses garde-fous et les procédures de mise à jour tiennent ensemble.