Le XRP Ledger comble une faille de 2015 qui permettait de créer des XRP à partir de rien : ce que cela change pour vos cryptos

Le XRP Ledger a révélé le 9 octobre 2026 une anomalie restée près de onze ans dans le module de paiement de la chaîne. Celui qui l'aurait exploitée aurait pu créer des XRP bien au-delà de l'offre totale, en une seule transaction valide. La faille est comblée depuis le 25 septembre avec la version xrpld 3.4.1, et RippleX écrit dans son rapport qu'aucun indice ne laisse penser qu'elle a été utilisée sur un réseau public.

Il ne s'agit donc pas d'une alerte sur une attaque en cours. Reste à clarifier votre propre dispositif : où se trouvent vos pièces, qui exploite le serveur derrière elles, et quelle version y tourne. Cet article replace le rapport de divulgation dans son contexte, explique l'erreur de calcul en termes simples et la traduit en points qu'un investisseur en Europe peut vérifier lui-même.

Dépassement dans le module de paiement : ce que révèle le rapport du 9 octobre

Le rapport de divulgation de xrpld 3.4.1 décrit deux constats distincts. Le plus grave concerne le module de paiement, c'est-à-dire la partie du logiciel qui achemine un paiement à travers les offres du carnet d'ordres de la chaîne et calcule ce que le payeur doit céder et ce que le bénéficiaire doit recevoir.

Le constat a été transmis le 22 septembre 2026 par le programme de primes aux bogues du XRP Ledger, le canal par lequel les chercheurs en sécurité déposent des vulnérabilités contre récompense. Le rapport cite Cayden Liao et Veria AI comme auteurs de la découverte. Le constat a d'abord été classé « Major ». Après l'avoir reproduit, l'équipe de RippleX a relevé la gravité au niveau critique.

La portée tient en une phrase dans le rapport : un attaquant aurait pu créer des XRP dépensables bien au-delà de l'offre totale, et cela en une seule transaction confirmée. La mise de départ aurait été modeste. Il fallait quelques centaines de XRP en réserve, c'est-à-dire le dépôt que le réseau exige pour les offres ouvertes et qu'il restitue après leur dénouement, plus les frais habituels. Les versions xrpld 3.4.0 et toutes les plus anciennes étaient concernées.

Comment une addition sans borne pouvait dépasser les 100 milliards de XRP

L'erreur de calcul en une phrase

Le module de paiement additionnait les montants de plusieurs offres au moyen d'un entier de 64 bits, sans vérifier si le résultat tenait dans cette largeur. Un dépassement, c'est exactement ce cas de figure : lorsqu'une somme excède la plus grande valeur représentable, elle ne déclenche pas d'erreur mais repart de zéro. Une très grande somme devient ainsi un très petit nombre.

Concrètement, selon le rapport : les fournisseurs des offres étaient payés intégralement, tandis que l'acheteur n'était débité que du minuscule reliquat issu du rebouclage. L'écart naissait de rien. Le déclenchement était possible avec quelques centaines d'offres délibérément mal valorisées dans le carnet d'ordres, qu'un paiement unique venait ensuite ramasser d'un coup.

Ce que le contrôle de l'offre a laissé passer

Le XRP Ledger dispose contre ce genre de situation d'une protection propre, l'invariant. Un invariant est une règle qui doit être respectée après chaque transaction, faute de quoi le réseau rejette l'opération. L'une d'elles énonce qu'aucun XRP ne peut être créé.

Ce contrôle s'exécutait au sein de la même anomalie et recourait au même mode de calcul non vérifié. Il ne voyait donc aucune hausse là où il y en avait une. Deux couches de protection ont cédé parce que toutes deux reposaient sur la même hypothèse. Le rapport fait remonter l'anomalie à la mise en œuvre du module de paiement en 2015.

xrpld 3.4.1 : une correction sans amendement, effective au démarrage

Les modifications des règles du XRP Ledger passent normalement par un amendement. Un amendement est une modification de règle soumise au vote des validateurs, qui ne s'applique à l'ensemble du réseau qu'après une phase d'adhésion. Les validateurs sont les serveurs qui confirment l'ordre des transactions.

Pour ce constat, RippleX a délibérément choisi une autre voie. Les contrôles de dépassement dans la somme des offres et dans la combinaison de plusieurs chemins de paiement s'appliquent sans vote, dès qu'un serveur démarre en 3.4.1. L'invariant compte depuis lors avec un compteur plus large. Le rapport parle d'une exception réfléchie, justifiée par la gravité du constat.

Pour les exploitants, il en découle une obligation claire. Le rapport indique que tous les exploitants de serveurs doivent passer en 3.4.1 ou plus récent afin de rester synchronisés avec le réseau. Celui qui reste sur une version antérieure est, depuis l'activation du 9 octobre, bloqué par l'amendement : il demeure sur un état des règles que le reste du réseau a déjà dépassé.

Chronologie du 22 septembre au 9 octobre

Le rapport expose le déroulé, et les intervalles qu'il contient constituent le véritable constat. Un jour s'est écoulé entre le signalement et une correction aboutie.

Le 22 septembre 2026, le dépassement est arrivé et a été reproduit. Le 23 septembre, la correction se trouvait dans la branche de publication de la 3.4.1. Le 24 septembre, l'équipe a conclu qu'un scénario de simple perturbation par cette voie ne tenait guère. Le 25 septembre, xrpld 3.4.1 a été publiée, et dans le même temps une phase d'adhésion de deux semaines s'est ouverte pour la seconde correction. Le 9 octobre, les deux modifications de règles sont devenues actives sur le réseau principal, et le rapport a paru le même jour.

Deux semaines entre la livraison et la divulgation relèvent de l'intention, non de l'omission. Tant qu'une large part des serveurs tourne encore sur l'ancienne version, une description précise de l'anomalie vaut mode d'emploi. Elle a été publiée le jour où la modification de règle était en place dans le réseau.

Cinq des huit rapports de divulgation du XRPL datent de 2026 : notre propre décompte

Savoir si un constat isolé est un accident ne se voit qu'à la série. Nous avons donc dénombré toutes les publications du blog du XRPL et isolé les rapports de divulgation. Sur 273 publications figurent huit rapports de ce type, et cinq d'entre eux portent une date de 2026.

Les cinq de cette année portent sur l'amendement Batch en février, le traitement des montants de transaction en mars, un afflux de messages de manifeste signalé le 30 juillet, les frais et réserves parrainés au titre de XLS-68 signalés le 7 août, ainsi que le rapport sur la 3.4.1 du 9 octobre. Les trois plus anciens se répartissent sur novembre 2024, avril 2025 et septembre 2025. cryptoticker.io a établi lui-même ce relevé le 10 octobre 2026.

Le chiffre se lit dans deux sens, et seule la mention des deux est honnête. Davantage de rapports peut signifier que l'on trouve davantage, parce qu'un programme de primes et un concours comme la session Sherlock Attackathon cherchent précisément cela. Il est également concevable que la chaîne offre, avec chaque nouvel élément, davantage de surfaces susceptibles de coincer. Pour situer le dépassement, ce qui compte avant tout est qu'il provient du noyau ancien et non de l'une des nouvelles fonctions.

Amendement Batch et Permission Delegation : ce qui est devenu actif en plus le 9 octobre

Le second constat du rapport concerne Batch, une fonction issue de la proposition XLS-56 qui permet à un compte de soumettre jusqu'à huit transactions comme un tout. La spécification exige que chaque transaction interne se trouve dans un champ déterminé. Le serveur ne le vérifiait pas, de sorte que d'autres champs pouvaient aussi servir d'enveloppe.

Plus grave encore, l'ensemble des enveloppes admissibles variait selon la version du logiciel. Deux serveurs auraient donc pu apprécier différemment la même opération, et c'est précisément ce qui menace l'accord au sein du réseau. Les versions 3.3.0 et 3.4.0, avec l'amendement BatchV1_1 encore inactif, étaient concernées. Le rapport cite comme origine le signalement F48 de l'Attackathon, d'abord classé faible. Denis Angell, de la XRPL Foundation, a constaté le 18 septembre que la première correction était incomplète, et Mayukha Vadari, de RippleX, a mis au jour le risque pour l'accord. Selon le rapport, aucun dommage n'est survenu : aucune perte d'avoirs, aucune clé exposée, aucune défaillance de l'accord.

Depuis le 9 octobre, le réseau rejette toute transaction Batch dont l'enveloppe est incorrecte, grâce à la modification de règle fixBatchV1_2, devenue active le même jour que BatchV1_1. Notre article du 1er octobre décrivait le cadre de dates dans lequel cette série de modifications pouvait s'appliquer au plus tôt, et la question alors ouverte était de savoir pourquoi certaines parties tardaient : le XRP Ledger et la date de Permission Delegation. Le rapport apporte la réponse. Derrière le retard se trouvait le retrait de voix, qui a empêché une activation avec une correction incomplète.

63,13 milliards de XRP sur 99,99 milliards : la limite d'offre au cœur de la promesse

Les XRP ont été créés une fois et ne sont plus émis depuis. Sur une offre totale de 99,99 milliards d'unités, 63,13 milliards circulent, le reste étant immobilisé ou détenu par l'entreprise. La capitalisation boursière, c'est-à-dire l'offre en circulation au cours actuel, s'établit à environ 88,8 milliards de dollars au 10 octobre 2026. Le XRP occupe ainsi le cinquième rang des plus grandes cryptomonnaies.

Cette fermeté de l'offre est le point où le dépassement fait mal. Une faille qui crée des unités dépensables au-delà de la limite ne touche pas une fonction annexe, mais la promesse sur laquelle repose le cours. Une attaque menée à bien n'aurait pas seulement modifié l'offre sur le papier ; elle aurait endommagé le contrôle par lequel le réseau remarque les variations d'offre.

Le classement en critique se comprend donc, même si aucun avoir n'a été perdu. L'étalon, pour de tels constats, est le dommage possible et non le dommage survenu. Et celui-ci portait ici sur le chiffre qui soutient tout le modèle.

Comment vérifier où se trouvent vos XRP en cas de coup dur

La version logicielle d'un serveur n'est pas une chose qu'un investisseur peut changer de l'extérieur. Ce qui se vérifie, c'est la chaîne des responsabilités : qui détient les pièces, qui exploite la technique en dessous, et qui il faudrait contacter en cas de coup dur.

Plateforme, courtier ou conservation personnelle

Si les XRP se trouvent sur une plateforme d'échange, celle-ci exploite le raccordement à la chaîne et répond de la version. L'investisseur y dispose d'un droit au retrait, non d'un accès direct aux pièces. Les lieux de négociation qui opèrent en Europe sous agrément, et les frais que cela implique, figurent dans notre panorama des meilleures plateformes crypto.

En conservation personnelle, la clé reste chez le détenteur et le raccordement passe par un prestataire ou par un serveur propre. Celui qui utilise un logiciel de portefeuille devrait le mettre à jour après un signalement de ce type, car de nombreux programmes recourent à un raccordement fourni avec eux. Avec un nœud propre, l'obligation du rapport s'applique directement : version 3.4.1 ou plus récente, sinon le serveur sort du consensus.

Trois questions soutiennent cette vérification. Premièrement : l'encours se trouve-t-il chez un prestataire établi et agréé dans l'Union européenne, ou sur une plateforme sans supervision européenne ? Deuxièmement : le prestataire a-t-il annoncé une maintenance ou une mise à jour après le 25 septembre ? Troisièmement : comment se déroulerait un retrait si le réseau était à l'arrêt pendant des heures ?

La conservation sous MiCA : une créance plutôt qu'une possession

Depuis MiCA, le règlement européen sur les marchés de crypto-actifs, les prestataires qui conservent ou échangent des crypto-actifs pour le compte de clients doivent être agréés comme prestataires de services sur crypto-actifs. Parmi leurs obligations figurent la séparation des avoirs des clients de leurs avoirs propres et la responsabilité en cas de perte des valeurs conservées.

Cela déplace la question sans la résoudre. Un conservateur agréé est joignable et engage sa responsabilité, mais il se situe entre le détenteur et la chaîne. La conservation personnelle inverse la logique : aucun tiers ne peut bloquer l'encours, et personne ne répond d'une clé perdue. La forme adaptée dépend du montant et de la fréquence des opérations.

Face à une anomalie de protocole comme celle-ci, les deux n'aident que dans une certaine mesure. Une faille dans le module de paiement agit sur la chaîne, non sur l'appareil du détenteur. Ce que la conservation détermine, c'est la rapidité avec laquelle quelqu'un peut réagir s'il faut arrêter ou reconstruire un réseau.

Cours du XRP à 1,41 dollar : le marché n'a pas bougé sur l'annonce

Le XRP cote 1,41 dollar au 10 octobre 2026, en hausse de 1,1 % par rapport à la veille. L'amplitude du jour va de 1,37 à 1,41 dollar. Sur une semaine, le recul atteint 5,6 %, sur trente jours la hausse est de 0,8 %.

Les niveaux des prochains jours découlent de cette amplitude. Vers le bas, le plus bas du jour se situe à 1,37 dollar ; vers le haut, le plus haut du jour borne la progression à 1,41 dollar. Que la divulgation du 9 octobre n'ait laissé aucune trace est cohérent avec son contenu : ce qui a été signalé est une faille comblée, sans indice d'exploitation, et non un incident en cours.

Notre appréciation : une anomalie restée onze ans n'est pas un cas isolé

Du point de vue de la rédaction, le traitement de ce constat est le pendant de l'anomalie elle-même. Un jour du signalement à la correction, deux semaines jusqu'à la divulgation, une correction sans vote là où voter aurait pris trop de temps : voilà la conduite que l'on attend d'un réseau de cette taille, et elle est documentée dans le rapport.

L'autre versant figure dans notre propre décompte. Cinq rapports de divulgation sur huit en une seule année, et un constat issu du noyau de 2015 que deux couches de protection ont laissé passer en même temps parce qu'elles utilisaient le même mode de calcul. Celui qui en conclut que la chaîne est désormais auditée en lit trop. L'origine du constat plaide contre cette lecture : du code qui tournait sans histoire depuis des années, et non une fonction fraîchement bâtie. Pour une appréciation du XRP comme placement, l'épisode ne change rien aux chiffres ; il change quelque chose à la question de l'effort de vérification que les fondations réclament encore.

Correctif du XRPL : sans la version 3.4.1, un nœud sort du consensus

1. Clarifier la responsabilité. Regardez où se trouvent vos XRP et qui exploite le raccordement à la chaîne. Chez un prestataire, ce qui compte est son agrément et la séparation des avoirs des clients. Les plateformes qui opèrent sous supervision européenne figurent dans notre panorama des plateformes crypto réglementées.
2. Suivre vous-même l'état de la chaîne. L'activation des modifications de règles et la version d'un serveur sont consultables publiquement. Celui qui suit cela régulièrement remarque un basculement avant le signalement suivant. Les outils pour le faire figurent dans notre panorama des plateformes d'analyse.
3. Documenter encours et durées de détention. Après un incident de protocole, un relevé propre de vos entrées et sorties compte, y compris pour la fiscalité. En Allemagne, la durée de détention d'un an détermine si un gain est imposable. La manière d'en garder la trace figure chez les logiciels fiscaux et suiveurs de portefeuille.

L'épisode se relit à la source même : dans le rapport de divulgation de xrpld 3.4.1 et dans l'annonce de la version 3.4.1 du 25 septembre.

(Au 10 octobre 2026. Cet article ne constitue pas un conseil en investissement. Les cours et les grilles tarifaires évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)