Une faille de dépassement d'entier dans le XRP Ledger aurait permis à une seule transaction de créer plus de XRP que la totalité de l'offre existante. RippleX, la branche de développement de Ripple, et la XRPL Foundation ont divulgué et corrigé la faille, probablement présente depuis 2015, fin septembre 2026. Rien n'indique qu'elle ait jamais été exploitée.

Un plafond d'offre qui aurait pu être brisé

Le XRP Ledger est la blockchain décentralisée derrière le XRP. Il gère les paiements et les échanges via un carnet d'ordres intégré, et le moteur de paiement est le composant qui fait correspondre les paiements aux offres qui y sont placées. L'offre totale s'élevait à 100 milliards de XRP au lancement. Il n'y a ni minage ni inflation ; seuls les frais de transaction brûlés réduisent légèrement l'offre. Ce plafond fixe repose sur un invariant au niveau du registre — la règle selon laquelle aucune transaction ne peut créer de XRP — et c'est précisément cette garantie que la faille de dépassement d'entier a fragilisée.

La version 3.4.1 du logiciel serveur xrpld est sortie le 25 septembre, et le rapport de divulgation a suivi 14 jours plus tard. Avant cela, plus de 80 % des validateurs de la Default Unique Node List (UNL) avaient déjà effectué la mise à jour. La faille affectait xrpld 3.4.0 et toutes les versions antérieures. Veria Labs, qui a signalé la faille, calcule qu'une seule transaction d'exploitation aurait créé environ 18 000 milliards de XRP.

Comment la faille aurait pu frapper des XRP de toutes pièces

Le moteur de paiement additionnait les montants de toutes les offres qu'un paiement consommait dans le carnet d'ordres, en utilisant une addition d'entiers 64 bits sans vérification de dépassement. Si la somme devenait assez grande, la valeur revenait à un petit nombre. Chaque propriétaire d'offre aurait reçu le paiement intégral, tandis que le registre ne débitait l'acheteur que de la somme redimensionnée. La différence serait alors apparue sous forme de nouveaux XRP.

Deux garde-fous auraient dû empêcher cela. Cependant, l'invariant stipulant qu'aucune transaction ne peut créer de XRP utilisait la même arithm sujette au dépassement. En outre, la vérification de solde par compte ne se déclenche qu'au-delà de l'offre totale, alors que les XRP créés seraient tombés dans de nombreux comptes.

Pour l'attaque, un acteur aurait créé des centaines de comptes, chacun offrant une infime fraction d'un token contre une énorme quantité de XRP. Un seul paiement aurait ensuite consommé toutes les offres, et chaque compte impliqué aurait pu appartenir à l'attaquant. Les coûts se montaient à quelques centaines de XRP en réserves récupérables plus les frais, si bien que l'attaquant n'avait pas besoin d'un solde de départ important.

Néanmoins, personne n'aurait pu déclencher le dépassement par accident. Les paiements normaux n'atteignent jamais la somme requise, car aucun trader réel ne coterait de tels prix. Le rapport indique également qu'il n'existe aucune preuve d'exploitation sur un réseau public. Cayden Liao de Veria Labs explique que l'exploit combine deux failles qui, prises isolément, seraient chacune de faible gravité, et soupçonne que c'est la raison pour laquelle personne n'avait trouvé cette vulnérabilité plus tôt.

Signalée via le programme de bug bounty

Cayden Liao et Veria AI ont signalé la vulnérabilité le 22 septembre via le programme de bug bounty du réseau, la classant initialement « Major ». RippleX a reproduit l'attaque et relevé la classification en « critical », puis a développé le correctif en privé. Un jour plus tard, le correctif est arrivé dans la branche de version 3.4.1 et a été livré dans la release candidate 3.4.1-rc1. Depuis, le moteur de paiement vérifie la présence d'un dépassement lors de l'addition des montants des offres ; si la somme dépasse la capacité, cette partie du paiement échoue.

Seul Veria Labs a fourni des détails sur la découverte elle-même. L'entreprise indique qu'un agent d'IA a trouvé la faille et construit un exploit fonctionnel. En revanche, le rapport de divulgation ne cite que Liao et Veria AI comme rapporteurs. Le chiffre d'environ 18 000 milliards de XRP provient du calcul de Liao et équivaudrait à 184 fois l'offre totale. Veria indique également avoir reçu le bounty maximal de 250 000 USD, bien que le rapport ne mentionne aucun montant. Ce type de programme est un mécanisme standard sur les grandes réseaux blockchain pour récompenser la divulgation responsable.

Selon le rapport, la faille était probablement présente dans le code depuis le développement du moteur de paiement en 2015, et elle est passée inaperçue pendant environ une décennie. Ce cas s'inscrit dans la tendance plus large de la recherche de vulnérabilités assistée par IA, qui expose les failles plus rapidement — une perspective partagée par les développeurs de RippleX.

Un correctif sans amendement

Les changements de règles sur le XRP Ledger passent normalement par ce qu'on appelle des amendements, qui nécessitent le soutien de plus de 80 % des validateurs de confiance sur une période de deux semaines. Ce correctif, en revanche, a pris effet immédiatement à mesure que chaque serveur individuel était mis à jour. Le rapport le qualifie de premier changement délibéré de ce type au traitement des transactions depuis l'arrivée des amendements. Le jour de la sortie, plus de 80 % des validateurs de la Default UNL faisaient déjà tourner la version 3.4.1 ou ultérieure.

RippleX a justifié cette décision par la contrainte de temps : une sortie open source régulière aurait montré aux attaquants où se situait la faille des semaines avant que le correctif ne prenne effet. Les membres de la XRPL Foundation, de RippleX et les validateurs du XRPL ont donc convenu à l'avance que le risque justifiait une approche rapide. De leur point de vue, seules les failles les plus graves justifient cette étape, tous les autres changements passant toujours par des amendements.

« L'IA a changé la donne. On ne peut pas glisser un correctif de faille critique dans un processus de publication publique de routine, il sera repéré et soumis à de l'ingénierie inverse immédiatement. » — Mayukha Vadari, RippleX

Pourtant, l'équipe n'a publié le code source de la 3.4.1 sur GitHub qu'environ deux semaines après les binaires. Justin Bons, fondateur de Cyber Capital, a critiqué sur X le fait que le XRP ait fonctionné sur du code fermé pendant deux semaines. Un correctif silencieux avec divulgation différée est une pratique courante en sécurité logicielle, mais elle reste contestée dans un réseau décentralisé aux ambitions de gouvernance.

Une seconde faille dans la fonctionnalité batch

La version 3.4.1 a également corrigé une seconde faille, dans la fonctionnalité batch (XLS-56), qui affectait xrpld 3.3.0 et 3.4.0. Un batch contient jusqu'à huit transactions internes, et selon la spécification, chacune doit se trouver dans un champ nommé RawTransaction. Le serveur ne le vérifiait pas. Une entrée de registre définitivement malformée pouvait donc en résulter, susceptible de perturber les indexeurs, les explorers et les SDK.

Une variante liée au consensus était plus grave. Avec des versions logicielles mixtes, une transaction forgée aurait pu bloquer la validation au prix d'un seul frais de transaction, bien qu'un attaquant n'aurait rien gagné on-chain. Le mainnet n'a subi aucun impact, BatchV1_1 n'y étant pas actif.

La découverte a d'abord émergée lors du Sherlock Attackathon, classée initialement « low ». Le 18 septembre, Denis Angell de la XRPL Foundation a confirmé qu'un correctif antérieur était incomplet. Quatre jours plus tard, Mayukha Vadari a identifié le risque de consensus. Ripple et l'opérateur de validateur Vet ont ensuite retiré leurs votes pour BatchV1_1, un amendement devant initialement s'activer le 29 septembre. La version a lancé l'activation en deux semaines de fixBatchV1_2, et depuis le 9 octobre, les deux amendements sont actifs sur le mainnet.

Un processus de revue renforcé

RippleX modifie donc son processus de revue. Désormais, chaque découverte de sécurité marquée comme corrigée passe par un nouveau test contre la release candidate, et l'équipe ne la clôt que lorsqu'un test reproduit la faille d'origine et que la candidate passe les tests. Parmi les garde-fous supplémentaires listés dans le rapport figurent les attackathons publics et le red teaming assisté par IA.

Les versions plus anciennes sont considérées comme « amendment-blocked » et ne restent plus synchronisées. Les opérateurs doivent donc mettre à jour leurs serveurs vers xrpld 3.4.1 ou une version ultérieure. La manière dont le réseau traitera sa prochaine découverte critique — par cette voie rapide réservée ou par un amendement régulier — montrera si cette approche reste l'exception que le rapport décrit.

Source : rapport de divulgation de vulnérabilité XRPL via Crypto Valley Journal