La XRP Ledger Foundation détaille son correctif d'urgence pour un bug critique lié à l'offre
Points clés
- •La XRP Ledger Foundation a déclaré qu'aucun XRP n'avait été créé grâce à la faille et qu'aucune preuve d'exploitation sur un réseau public n'a été trouvée.
- •L'exploitation nécessitait des centaines d'opérations délibérément construites ; un paiement normal ne pouvait en aucun cas déclencher la vulnérabilité.
- •La version 3.4.1 a été directement distribuée aux validateurs de la UNL par défaut avant la publication des binaires publics le 25 septembre, marquant le premier changement direct et délibéré du traitement des transactions depuis l'introduction du système d'amendements il y a plus de dix ans.
- •Environ 99,986 milliards de XRP existent sur une offre fixe de 100 milliards, et la Foundation indique que tous les soldes sont publiquement visibles, permettant à chacun de vérifier les chiffres de manière indépendante.
- •Les opérateurs de nœuds sont invités à exécuter xrpld version 3.4.1 ou plus récente, tandis que les détenteurs de XRP n'ont pas été invités à déplacer leurs fonds ni à remplacer leurs portefeuilles.
La XRP Ledger Foundation a expliqué comment les développeurs et les validateurs ont réagi à une vulnérabilité qui aurait permis à un attaquant de créer du XRP dépensable via un paiement délibérément construit. La Foundation a déclaré qu'aucun XRP n'avait été créé grâce à cette faille et qu'aucune preuve d'exploitation sur un réseau public n'a été trouvée.
La déclaration du 11 octobre s'est concentrée sur la réponse plutôt que de répéter le fonctionnement détaillé de la vulnérabilité. Une explication antérieure du bug est disponible dans le rapport de Coindoo. Le rapport de divulgation technique de la Foundation est disponible sur le site web du XRP Ledger.
Les données publiques du registre confirment l'affirmation concernant l'offre
Le XRP a été lancé avec une offre fixe de 100 milliards, et les frais de transaction sont détruits au fil du temps. La Foundation a indiqué qu'environ 99,986 milliards de XRP existent actuellement.
Le rapport de divulgation technique précise que l'équipe n'a trouvé aucune preuve que la vulnérabilité ait été exploitée sur un réseau public. Cette affirmation peut être vérifiée à l'aide de l'historique des transactions validées et des soldes des comptes du XRP Ledger, qui sont publiquement accessibles pour un examen indépendant via les explorateurs et autres services de données.
« Vous n'avez pas besoin de nous croire sur parole », a écrit la Foundation. Tout nouveau XRP apparaîtrait dans les soldes des comptes, car il n'existe aucune zone de solde cachée sur le XRP Ledger. La Foundation a déclaré surveiller le registre en continu et avoir vérifié l'offre tout au long de l'histoire du réseau, tandis que d'autres membres de la communauté ont effectué leurs propres vérifications.
Les registres publics ne peuvent pas révéler toutes les conversations privées antérieures à la divulgation ni établir l'intention derrière une attaque jamais soumise au réseau. Ils peuvent toutefois montrer les transactions validées, les variations de soldes visibles et l'offreregistrée. Ces informations permettent de contester les affirmations selon lesquelles de grandes quantités de XRP auraient été secrètement émises et dissimulées sur le réseau.
Pourquoi le correctif a été publié avant la divulgation technique
Dans le cadre du processus de gouvernance standard du XRP Ledger, les modifications des règles de transaction sont introduites par le biais d'amendements. Les validateurs doivent maintenir un soutien supérieur à 80 % pendant deux semaines avant qu'un amendement ne s'active. Ce processus laisse aux opérateurs le temps de procéder à la mise à niveau et permet au réseau d'adopter un changement au même moment.
Le correctif du dépassement de capacité a suivi une voie différente car la vulnérabilité était considérée comme un risque actif. Selon le rapport de divulgation, publier le code révélant la faille précise avant que les serveurs plus anciens ne soient protégés aurait pu faciliter l'identification de la voie d'attaque. La version 3.4.1 a donc appliqué la protection à mesure que chaque serveur était mis à niveau, au lieu d'attendre le processus public d'amendement habituel.
La Foundation a résumé son explication dans une publication sur X :
The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let’s clear them up.
- Was any XRP created?
No. XRP’s supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around that rule, and 3.4.1 fixed it 2 weeks ago.
You don’t need to trust us on this. All ledger data is public, and explorers and data sites read it every day. New XRP would show up in account balances for everyone to see. There is no hidden place for XRP on the XRP Ledger, every balance is public.
We monitor the XRP Ledger 24/7 and have verified the supply throughout the history of the ledger. Others in the community verified this too, and anyone can do the same.
Transaction fees are destroyed, so the supply is deflationary. About 99.986 billion XRP exist today.
- How did this go unnoticed, and what’s next?
No normal payment comes anywhere near triggering it. It took hundreds of deliberately constructed operations.
AI makes bugs like this faster to find, for the bad guys and the good guys.
Together with RippleX and the community, we will ensure the XRP Ledger is protected against such vulnerabilities. This means radically applying Formal Verification and AI adversarial testing, collaborating closely with security researchers, and strengthening the bug bounty program.
You’ll hear a lot more about this as we progress.
- XRP Ledger decentralization at the core of this.
A public fix shows attackers where the bug is, and AI makes that fast. With a normal amendment vote, the fix would have been public for weeks before it took effect, risking network security.
As a reaction to this, the XRPL community came together, and among them the XRP Ledger Foundation, RippleX, core devs and validators formed a social consensus and agreed on a path forward that involves shipping the fix directly. Patching a live network is never trivial, so the plan was also designed to minimize disruption for everyone running on it.
We shared the build with the default UNL validators, using the contact details each one publishes in its xrp-ledger.toml file. Public binaries followed the same day, September 25.
No single party could make that call alone. Every validator and node operator chooses what software to run, and 3.4.1 only became required through a normal amendment vote with more than 80% validator support for two weeks. Protocol changes still go through amendments.
Big thanks to Cayden Liao and Veria AI for finding and reporting this responsibly, to the XRPL core developers for building and testing the fix, and to every node operator who upgraded so quickly, especially the validators.
Full report:
— XRP Ledger Foundation (@XRPLF) October 11, 2026
La Foundation a décrit cette publication logicielle directe comme une réponse exceptionnelle plutôt que comme un remplacement de la gouvernance ordinaire. Son rapport indique qu'il s'agit du premier changement direct et délibéré du traitement des transactions depuis l'introduction du système d'amendements il y a plus de dix ans. Les futures modifications du protocole continueront, selon le rapport, à ex des amendements soutenus par les validateurs.
Les validateurs ont conservé le contrôle de l'installation du logiciel
La Foundation a déclaré avoir partagé la version corrigée avec les opérateurs des validateurs de la UNL par défaut avant de publier les binaires publics le 25 septembre. Ces opérateurs ont décidé s'ils exécuteraient ou non la nouvelle version. Ni la Foundation ni RippleX ne pouvaient imposer une mise à niveau sur des serveurs exploités de manière indépendante.
Cela a créé une courte période pendant laquelle les serveurs corrigés et non corrigés suivaient des règles différentes pour le chemin de paiement spécialisé. Selon le rapport du XRPL, une tentative d'exploitation pendant cette période aurait pu provoquer des divergences entre les versions et potentiellement perturber la validation. L'équipe a jugé ce risque préférable à celui de laisser ouverte une attaque d'inflation peu coûteuse et potentiellement irréversible pendant une période d'activation publique plus longue.
La réponse a été coordonnée par la XRP Ledger Foundation, RippleX, les développeurs du noyau et les validateurs, mais aucune organisation seule n'a pu prendre cette décision. Chaque validateur et opérateur de nœud choisit le logiciel qu'il exécute, tandis que le système d'amendements demeure le mécanisme rendant obligatoires les modifications du protocole.
Ce que la divulgation signifie pour les utilisateurs et les opérateurs
Le rapport n'a pas demandé aux détenteurs de XRP de déplacer leurs fonds ni de remplacer leurs portefeuilles. Pour les opérateurs de nœuds, le XRPL a indiqué que les serveurs doivent exécuter la version 3.4.1 d'xrpld ou une version plus récente pour rester synchronisés avec le réseau. En pratique, la mesure de remédiation annoncée concerne le logiciel assurant l'infrastructure du registre plutôt qu'une action de portefeuille demandée aux détenteurs de XRP.
La Foundation a également précisé qu'un paiement normal ne s'approcherait en aucun cas du déclenchement de la vulnérabilité. Son exploitation nécessitait des centaines d'opérations délibérément construites. Elle a ajouté que l'intelligence artificielle peut rendre la découverte de ce type de vulnérabilités plus rapide, tant pour les attaquants que pour les défenseurs.
Mesures de sécurité prévues
La Foundation a déclaré prévoir d'étendre l'utilisation de la vérification formelle et des tests adversaires par IA, de travailler plus étroitement avec des chercheurs externes en sécurité et de renforcer son programme de bug bounty. Ces mesures ne peuvent garantir qu'aucun problème critique ne réapparaisse, mais elles visent à améliorer les chances que les vulnérabilités soient identifiées avant une version de production.
Le rapport de divulgation décrit également une mesure de contrôle des versions. Les constatations de sécurité marquées comme corrigées doivent être re-testées sur le candidat à la publication contenant le correctif, et le problème initialement signalé doit être reproduit avant que constatation ne soit clôturée. Ce processus donne aux chercheurs externes une norme définie à laquelle les versions ultérieures peuvent être comparées.
La vulnérabilité a exposé une faiblesse sérieuse dans une règle conçue pour préserver l'offre fixe du XRP. La réponse a désormais produit une trace publique : un rapport de bug bounty, une mise à niveau accélérée des validateurs, une divulgation technique ultérieure et un ensemble d'engagements en matière de sécurité. La mesure dans laquelle ces engagements deviendront une pratique habituelle des futures procédures de publication déterminera la portée à long terme de l'incident.
Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil en investissement. Les versions logicielles et les détails des divulgations de sécurité peuvent évoluer à mesure que de nouvelles informations techniques deviennent disponibles.
Source : Coindoo.
