Le XRP Ledger a un plafond absolu de 100 milliards de XRP. Pendant environ onze ans, ce plafond n'était qu'une suggestion. Le 9 octobre 2026, la Fondation XRPL a publié un rapport de divulgation confirmant qu'une seule transaction astucieusement conçue aurait pu créer environ 18,4 billions de XRP dépensables, soit environ 184 fois l'offre totale, et que le code le permettant était présent dans le moteur de paiement depuis novembre 2015. Le bug a été trouvé par un agent d'IA, corrigé en trois jours, et déployé d'une manière que le ledger n'avait jamais utilisée auparavant. Personne ne l'a exploité. C'est la bonne nouvelle. Tout le reste de l'histoire mérite un examen plus approfondi.
Ce que le bug de dépassement du XRP Ledger a réellement fait
La faille se trouvait dans la partie du moteur de paiement qui gère un paiement traversant un carnet d'ordres. Lorsqu'un paiement consomme de nombreuses offres à la fois, le moteur additionne les montants qu'il doit à chaque propriétaire d'offre. Cette addition utilisait de simples entiers signés de 64 bits sans vérification de dépassement. Poussez le total au-delà de 2 puissance 64 et le compteur revient à un petit nombre, comme un compteur kilométrique de voiture qui passe de 999999 à 000000.
Voici la partie la plus laide. Le moteur facturait à l'acheteur le total après dépassement, qui était minuscule. Il payait à chaque propriétaire d'offre leur montant complet, non tronqué... La différence entre ces deux nombres représente des XRP qui n'existaient pas un instant plus tôt.
Le ledger dispose d'un filet de sécurité pour exactement ce genre de situation... Une vérification d'invariant appelée XRPNotCreated s'exécute après chaque transaction et refuse de valider tout ce qui augmente le total de XRP. Le problème est que l'invariant suivait le changement net de XRP en utilisant la même arithmétique 64 bits non vérifiée. Un crédit suffisamment important faisait également dépasser le compteur de l'invariant, de sorte qu'une transaction qui imprimait des billions de XRP ressemblait, pour la vérification de sécurité, à une simple destruction de frais. Deux bugs indépendants, écrits à deux ans d'intervalle, annulaient mutuellement leur protection.
Comment 256 offres totalisent 18 000 milliards de XRP
Veria Labs, le cabinet de sécurité dont l'agent d'IA a trouvé le bug, a publié l'arithmétique. L'attaque utilisait 256 offres. Chaque offre était vendue pour 2 puissance 56, plus un drop de XRP. Multipliez 256 par ce chiffre et le total atteint exactement 2 puissance 64, plus 256 drops. Le drop supplémentaire par offre compte : sans lui, la somme revient précisément à zéro, ce que le moteur rejetterait comme un paiement à sec. Avec lui, l'acheteur est facturé 256 drops, environ 0,000256 XRP, tandis que les 256 propriétaires d'offres reçoivent collectivement 2 puissance 64 drops... Cela représente 18 446 744 073 709 551 616 drops, soit environ 18,45 billions de XRP.
L'attaquant avait besoin de 256 comptes approvisionnés car chaque compte XRPL est plafonné à 100 milliards de XRP, bien en dessous du montant par offre réparti sur un seul compte. Il avait également besoin de quelques centaines de XRP en réserves et frais de transaction, tous récupérables. Aucun accès validateur n'était requis. L'attaque pouvait être répétée avec de nouveaux comptes... Veria a estimé la valeur à risque à environ 94 milliards de dollars, soit plus de soixante fois le vol de 1,5 milliard de dollars de Bybit qui détient actuellement le record d'un piratage crypto réellement survenu.
| Ingrédient | Valeur | Pourquoi c'est important |
|---|---|---|
| Offres consommées en un paiement | 256 | Sous la limite de 1 000 offres par traversée de carnet |
| Prix par offre | 2^56 + 1 drop | Reste sous la limite de 100 milliards de XRP par compte |
| Total calculé par le moteur | 2^64 + 256 drops | Revient à 256 drops en arithmétique 64 bits |
| Ce que l'acheteur a payé | 256 drops (0,000256 XRP) | La valeur après dépassement |
| Ce que les vendeurs ont reçu | Environ 18,45 billions de XRP | La valeur non tronquée, 184x l'offre totale |
| Coût pour l'attaquant | Quelques centaines de XRP, récupérables | Réserves plus frais |
| Accès validateur nécessaire | Aucun | N'importe quel compte approvisionné pouvait le faire |
Un agent d'IA l'a trouvé un lundi soir
Le rapporteur officiel est Cayden Liao de Veria Labs, avec l'agent d'IA de la firme crédité à ses côtés. Selon le propre compte de Veria, l'agent a été pointé vers la base de code rippled le 21 septembre, a signalé les deux dépassements, a compris qu'ils pouvaient être enchaînés, et a produit une preuve de concept fonctionnelle sur un réseau local... Un ingénieur fondateur a été réveillé à 4h du matin pour vérifier. Le matin du 22 septembre, l'équipe était suffisamment confiante pour le signaler via le programme de bug bounty du XRPL, le classant comme Majeur... RippleX l'a reproduit le même jour et l'a élevé à Critique. En toute honnêteté, Veria affirme que des agents de codage généralistes pointés vers le même code après la divulgation n'ont pas réussi à le trouver. Prenez cela avec les réserves habituelles d'une entreprise qui vend l'outil qui l'a fait. Le point plus large reste valable indépendamment. Le code d'agrégation BookStep date de novembre 2015 et l'invariant XRPNotCreated de février 2017. Le XRPL a versé plus d'un million de dollars en primes et réalisé plus d'une douzaine d'audits et de concours d'audit depuis 2024. Des humains et des cabinets d'audit ont examiné ce code pendant une décennie et l'ont manqué. Le schéma devient familier. Coldcard a perdu environ 1 367 BTC cet été à cause d'un bug de firmware vieux de cinq ans que son fabricant soupçonne d'avoir été trouvé avec l'aide de l'IA... le vieux code n'est plus sûr simplement parce qu'il est vieux.
Pourquoi le correctif a contourné le vote des validateurs
C'est ici que l'histoire cesse d'être une victoire de sécurité propre et devient un débat de gouvernance. Le XRP Ledger modifie normalement les règles de transaction via des amendements. Une nouvelle règle est livrée dans le logiciel désactivée, les validateurs votent dessus, et elle s'active seulement après avoir maintenu plus de 80 % de soutien sur la liste de nœuds uniques par défaut pendant deux semaines consécutives. Le système est en place depuis plus d'une décennie et n'a jamais été délibérément contourné pour un changement de traitement des transactions.
Jusqu'au 25 septembre. Le correctif de dépassement a été livré directement dans xrpld 3.4.1 sans barrière d'amendement. Il a pris effet sur chaque serveur dès que ce serveur a été mis à jour... Le raisonnement de la Fondation XRPL est simple : un vote d'amendement aurait publié le correctif, et donc le bug, pendant deux semaines avant qu'il ne prenne effet. Quiconque lisant le diff aurait eu quinze jours pour imprimer 18 000 milliards de XRP. La Fondation affirme que la décision a été prise conjointement par elle-même, RippleX, les développeurs principaux et les validateurs, et qu'aucune partie seule n'aurait pu prendre la décision.
L'approche comportait son propre risque, ce que le rapport de divulgation admet. Si quelqu'un avait tenté l'exploit alors que le réseau était divisé entre serveurs corrigés et non corrigés, les deux groupes auraient été en désaccord sur l'état du ledger... Dans le pire des cas, le réseau s'arrête. L'équipe a jugé qu'un arrêt possible était préférable à une explosion certaine de l'offre, ce qui est difficile à contester. Plus de 80 % des validateurs UNL par défaut exécutaient la 3.4.1 dans les heures suivant la sortie le 25 septembre.
| Date | Événement |
|---|---|
| Nov 2015 | Code de sommation des offres BookStep écrit avec addition 64 bits non vérifiée |
| Fév 2017 | Invariant XRPNotCreated ajouté, utilisant la même arithmétique non vérifiée |
| 21 Sep 2026 | L'agent d'IA de Veria Labs signale les deux dépassements et les enchaîne |
| 22 Sep 2026 | Signalé via le bug bounty XRPL, reproduit par RippleX, élevé à Critique |
| 23 Sep 2026 | Correctif fusionné en privé dans le candidat de version 3.4.1 |
| 25 Sep 2026 | xrpld 3.4.1 publié, plus de 80 % des validateurs UNL par défaut mis à jour |
| 8 Oct 2026 | Veria Labs reçoit la prime maximale de 250 000 $ |
| 9 Oct 2026 | Rapport de divulgation publique publié, l'amendement Batch fix s'active |
| 12 Oct 2026 | ZachXBT qualifie publiquement la prime de trop faible |
La bataille de décentralisation qui a suivi
En bref, Justin Bons de Cyber Capital, un critique de longue date du XRP, a utilisé l'épisode pour affirmer que commercialiser le XRP auprès du grand public comme décentralisé équivaut à une fraude. Ses griefs spécifiques : la version du 25 septembre a été distribuée uniquement sous forme de binaires compilés, avec le code source temporairement retenu, et les opérateurs ont été poussés à mettre à jour un binaire qu'ils ne pouvaient pas inspecter. Le rapport de divulgation du XRPL confirme que la source a été publiée plus tard, sans préciser quand.
En pratique, la contre-argumentation est venue autant des opérateurs de validateurs indépendants que de la Fondation. XRP Kuwait, qui gère son propre nœud, l'a formulé ainsi : la coordination n'est pas la même chose que le contrôle. Les opérateurs indépendants ont lu le même avis, sont arrivés à la même conclusion, et ont mis à jour. Personne ne les a forcés. Bitcoin a fait la même chose, notamment avec le bug d'inflation de 2018 dans Bitcoin Core 0.16.x, lorsque les développeurs ont discrètement livré un correctif avant d'expliquer ce qu'il corrigeait. Chaque chaîne avec un bug sérieux finit par faire face au choix entre transparence et survie, et chacune d'elles a choisi la survie. Au final, là où Bons a un point valable, c'est sur les binaires. Livrer un binaire non vérifiable et demander aux validateurs de l'exécuter immédiatement est un exercice de confiance, aussi justifié soit-il. La version honnête de la position du XRPL est que son ensemble de validateurs a suffisamment fait confiance à la Fondation et à RippleX pour exécuter du code non révisé pendant quelques jours. Que vous appeliez cela décentralisé dépend de ce que vous pensez que le mot signifie.
250 000 $ étaient-ils suffisants pour un bug de 94 milliards de dollars
Veria Labs a reçu le paiement de niveau critique supérieur du programme XRPL de 250 000 $ le 8 octobre. Veria l'a qualifié de probablement la plus grande prime jamais versée pour un bug trouvé entièrement par un agent d'IA. Quatre jours plus tard, l'enquêteur blockchain ZachXBT l'a qualifié de mauvaise blague. Son argument : un écosystème dont la trésorerie détient des milliards a payé un quart de million pour une découverte qui aurait pu mettre fin à l'actif. Et cet écart est exactement l'incitation qui pousse le prochain chercheur à vendre à un attaquant à la place... Il a suggéré sept chiffres comme plancher et a pointé vers une récompense à sept chiffres apparemment versée dans l'écosystème Zcash pour un récent bug de contrefaçon. Ni Ripple ni la Fondation n'avaient répondu publiquement au moment de la rédaction.
Les deux camps ont raison sur des choses différentes. Le programme a payé son maximum annoncé, le chercheur a divulgué de manière responsable, et le correctif est arrivé avant que quiconque en dehors de la boucle ne le sache. C'est le système qui fonctionne. Il est également vrai que 250 000 $ représentent 0,27 % des 94 milliards de dollars à risque, et que tout attaquant avec 256 comptes et quelques centaines de XRP aurait pu prendre les 99,73 % restants. Les plafonds de primes écrits quand le XRP valait une fraction de sa valeur marchande actuelle ne s'adaptent pas à la chose qu'ils protègent.
Ce que les détenteurs de XRP et les joueurs de crypto devraient en retenir
Le correctif est côté serveur. Votre portefeuille, vos clés et votre solde n'ont jamais été impliqués et rien ne doit être mis à jour de votre côté. Le plafond d'offre a tenu parce que le bug a été attrapé, pas parce que l'invariant a fonctionné. La seconde moitié de cette phrase est celle qui mérite d'être retenue.
Il y a trois leçons pratiques ici. Premièrement, le fait que le code soit en service depuis dix ans a cessé d'être un argument de sécurité. L'audit assisté par IA rend les vieux dépassements faciles à trouver, et les attaquants louent les mêmes modèles que les chercheurs. Deuxièmement, les processus de gouvernance conçus pour le déploiement de fonctionnalités ne sont pas conçus pour les correctifs critiques. Et chaque chaîne devrait décider à l'avance comment elle gérera le prochain plutôt que d'improviser sous pression. Troisièmement, les plafonds de primes de bug bounty devraient suivre la valeur sécurisée. Un plafond fixe qui semblait généreux en 2022 est une invitation en 2026. De plus, pour le public des jeux d'argent, la pertinence est simple. Le XRP est devenu un rail de dépôt standard dans les casinos crypto car il se règle en quatre secondes pour une fraction de centime. Et cette vitesse dépend de l'exactitude des règles du ledger. Les plateformes qui automatisent les paiements, y compris CryptoCasino.Vegas, font confiance aux invariants des chaînes chaque fois qu'un retrait XRP est validé sans qu'un humain ne le regarde. Ces invariants ont tenu cette fois grâce à un chercheur et un agent d'IA travaillant toute la nuit, et c'est une marge plus mince que le plafond de 100 milliards ne l'a jamais laissé entendre.
L'analyse technique complète, incluant les deux emplacements de dépassement et l'arithmétique renforcée qui les a remplacés, se trouve dans le rapport de divulgation de vulnérabilité de la Fondation XRPL pour xrpld 3.4.1.
