Aperçu
Une vulnérabilité critique du XRP Ledger qui était restée dans le moteur de paiement pendant environ une décennie aurait théoriquement pu permettre à un attaquant de créer des XRP dépensables au-delà des règles d'approvisionnement prévues du registre. XRPL a divulgué le problème le 9 octobre 2026, après qu'il ait été signalé en privé via le programme de bug bounty XRPL le 22 septembre. La vulnérabilité affectait xrpld 3.4.0 et les versions antérieures et a été corrigée dans xrpld 3.4.1, publié le 25 septembre.
La vulnérabilité du XRP Ledger impliquait un dépassement d'entier lorsqu'un paiement consommait des centaines d'offres de carnet d'ordres spécialement construites. Les propriétaires individuels des offres pouvaient recevoir leurs montants complets en XRP tandis que l'acheteur n'était facturé que d'un petit total après bouclage. Plus grave encore, l'invariant existant du registre « aucun XRP créé » utilisait un chemin arithmétique similaire et pouvait déborder de la même manière, empêchant cette vérification de sécurité de détecter la discrepancy.
XRPL affirme n'avoir trouvé aucune preuve que la vulnérabilité ait été exploitée sur un réseau public, et les paiements normaux ne pouvaient pas la déclencher accidentellement. L'attaque nécessitait des offres délibérément conçues avec des prix économiquement irréalistes. Même ainsi, l'incident soulève une question de sécurité plus profonde : la politique monétaire fixe d'une blockchain n'est aussi solide que le logiciel qui applique chaque transition de solde.
Points clés à retenir
- Le bug semble avoir existé depuis que le moteur de paiement actuel du XRPL a été écrit en 2015.
- Une transaction délibérément construite aurait théoriquement pu créer des XRP dépensables.
- XRPL n'a trouvé aucune preuve d'exploitation sur un réseau public.
- L'invariant d'approvisionnement existant pouvait échouer parce qu'il reproduisait le même comportement de dépassement.
xrpld 3.4.1a ajouté une arithmétique vérifiée et une vérification d'approvisionnement indépendante plus forte.
Qu'était la vulnérabilité du XRP Ledger ?
La vulnérabilité se trouvait dans la gestion de la liquidité du carnet d'ordres par le moteur de paiement du XRP Ledger. Lorsqu'un paiement traverse plusieurs offres, le moteur doit calculer combien de XRP le payeur doit au total. Chaque montant individuel pouvait être valide, mais le calcul agrégé utilisait un entier de 64 bits sans protection suffisante contre le dépassement.
Dans des conditions ordinaires, cela était effectivement inatteignable. L'approvisionnement normal en XRP et les prix réels du marché ne s'approchent pas du tout de la limite numérique requise pour faire déborder le compteur. Le problème n'est apparu que lorsqu'un attaquant a délibérément construit des centaines d'offres dans lesquelles chaque compte demandait une quantité extrêmement importante de XRP pour une infime quantité d'un autre jeton.
Un flux malveillant pourrait ressembler approximativement à ceci :
- Créer plusieurs centaines de comptes contrôlés.
- Placer des offres délibérément irréalistes depuis ces comptes.
- Construire un paiement conçu pour consommer ces offres ensemble.
- Pousser le calcul agrégé des XRP au-delà de la limite entière.
- Provoquer le bouclage du total vers un nombre beaucoup plus petit.
Le moteur pouvait alors créditer les propriétaires des offres individuellement tout en ne facturant à l'acheteur que le total après dépassement. Comme l'attaquant pouvait également contrôler les comptes des propriétaires des offres, la différence devenait effectivement de nouveaux XRP.
Les ingénieurs de XRPL ont reproduit l'attaque localement et confirmé que les XRP résultants pouvaient ensuite être transférés. Le problème a par conséquent été relevé de Majeur à sévérité critique.
La vulnérabilité du XRP Ledger pouvait-elle vraiment créer des XRP ?
Oui, théoriquement. Ce n'était pas simplement une erreur d'affichage comptable. La divulgation technique de XRPL indique que l'exploit aurait pu créer des XRP qui se comportaient comme des XRP ordinaires après la validation de la transaction malveillante. Ces soldes auraient pu être déplacés, échangés ou envoyés vers des plateformes d'échange.
Cela ne signifie pas que des XRP ont été historiquement surémis. XRPL rapporte qu'il n'a trouvé aucune preuve que l'exploit se soit produit sur un réseau public. La différence entre ces deux affirmations est essentielle : la vulnérabilité pouvait violer la contrainte d'approvisionnement prévue, mais il n'existe actuellement aucun événement d'approvisionnement historique confirmé qui y soit associé.
L'attaque ne pouvait pas non plus se produire accidentellement lors d'un trading normal sur le DEX. Les offres du carnet d'ordres devaient être évaluées de manière si irréaliste que la liquidité normale du marché s'exécuterait avant de les atteindre. Un paiement devait également être intentionnellement construit pour consommer suffisamment de ces offres ensemble afin de déclencher le dépassement.
Il convient donc de comprendre cela comme un chemin d'exécution à faible probabilité avec un impact théorique extrêmement élevé, plutôt que comme une erreur que des utilisateurs ordinaires de XRP auraient pu déclencher sans le savoir.
Pourquoi la vérification de sécurité de l'approvisionnement de XRPL a-t-elle échoué ?
La partie la plus importante techniquement de l'incident n'est pas simplement qu'un dépassement d'entier existait. Les logiciels financiers matures contiennent souvent plusieurs couches défensives conçues pour détecter exactement ce genre de résultat inattendu.
XRPL en avait une : un invariant de transaction destiné à garantir qu'une transaction ne pouvait pas créer de XRP. En principe, même si le moteur de paiement commettait une erreur comptable, l'invariant aurait dû remarquer que les soldes totaux en XRP augmentaient et rejeter la transaction.
Il ne l'a pas fait.
La raison est une défaillance classique de systèmes de sécurité censés être indépendants. L'invariant calculait les changements nets de XRP en utilisant un type similaire d'arithmétique non vérifiée. Lorsque le moteur de paiement débordait, le calcul de l'invariant pouvait déborder dans la même direction, faisant apparaître la transaction résultante comme n'ayant modifié l'offre de XRP que du montant des frais de transaction ordinaires.
Une vérification de sécurité n'est pas véritablement indépendante lorsqu'elle peut reproduire le même mode de défaillance que le système qu'elle vérifie.
Une seconde protection vérifiait si le solde d'un compte individuel dépassait l'offre totale de XRP. Cela n'a pas non plus permis d'arrêter l'attaque, car les XRP nouvellement créés pouvaient être répartis sur des centaines de comptes, maintenant chaque solde individuel en dessous de la limite.
La remédiation a donc traité à la fois le bug immédiat et l'architecture défensive. xrpld 3.4.1 a ajouté des vérifications explicites de débordement lorsque les montants sont agrégés à travers les offres et les chemins de paiement. XRPL a également modifié l'invariant « aucun XRP créé » pour utiliser un compteur plus large qui ne peut pas boucler dans les mêmes conditions.
Pourquoi un bug de 2015 est-il resté caché si longtemps ?
La réponse réside en partie dans la différence entre les valeurs économiques réalistes et les limites informatiques théoriques. Les paiements XRP individuels fonctionnent à plusieurs ordres de grandeur en dessous de la plage nécessaire pour faire déborder une somme de 64 bits. Un trader normal pourrait utiliser XRPL pendant des années sans jamais créer quoi que ce soit ressemblant aux conditions numériques malveillantes.
Cela a rendu la faille difficile à exposer par un usage routinier. La logique vulnérable pouvait se comporter correctement à travers des milliards d'opérations normales tout en échouant catastrophiquement à une frontière artificielle.
La vulnérabilité démontre aussi pourquoi un code blockchain de longue durée ne devrait pas être automatiquement considéré comme sûr simplement parce qu'il a fonctionné pendant de nombreuses années. L'historique de production est une preuve utile, mais il teste principalement des états courants. Les attaquants recherchent délibérément des états que les utilisateurs normaux ne créent jamais.
XRPL a crédité son programme de bug bounty d'avoir trouvé le problème et a décrit une approche plus large de défense en profondeur qui inclut des audits indépendants, des attaques publiques, du fuzzing, du red teaming assisté par IA et de la vérification formelle. Il ajoute également une re-vérification des correctifs de sécurité par rapport aux versions candidates avant que les conclusions ne soient formellement closes.
Cette approche compte parce que la leçon de cet incident n'est pas que le code mature ne peut pas être digne de confiance. C'est que le code mature nécessite encore des tests adversariaux contre des hypothèses que les développeurs ont cessé de remettre en question des années plus tôt.
Que signifie ce bug pour l'offre fixe de XRP ?
XRP a commencé avec une offre initiale définie de 100 milliards de jetons, sans mécanisme protocolaire analogue au minage par preuve de travail qui crée continuellement des XRP supplémentaires. Les frais de transaction sont détruits plutôt que payés aux validateurs, de sorte que le chemin d'offre prévu est non inflationniste.
La vulnérabilité du XRP Ledger expose une distinction importante entre la politique monétaire en tant que règle et la politique monétaire en tant qu'application logicielle.
Une spécification de blockchain peut déclarer que de nouveaux XRP ne peuvent pas être créés, mais les nœuds appliquent finalement cette propriété par le code. Si la logique de transition de solde peut être manipulée pour violer la règle, alors la politique économique elle-même peut échouer même si la politique documentée n'a pas changé.
Cet incident n'a pas démontré que l'offre en circulation réelle de XRP avait été secrètement augmentée. XRPL affirme qu'aucune exploitation du réseau public n'a été trouvée. Mais il a démontré qu'avant le correctif, il existait un chemin d'exécution théorique capable de contourner l'une des contraintes monétaires les plus fondamentales du registre.
Cela rend cette vulnérabilité plus lourde de conséquences qu'une panne RPC temporaire ou un problème de connectivité des nœuds. Un réseau peut tolérer certaines perturbations d'infrastructure sans compromettre l'intégrité des actifs. Un bug capable de générer des unités dépensables touche la fondation comptable du registre lui-même.
Pourquoi le correctif importe plus que l'absence d'exploit
Il est tentant de rejeter une vulnérabilité une fois que les enquêteurs disent qu'elle n'a jamais été exploitée. Cela manquerait la leçon de sécurité la plus utile.
La chronologie de réponse de XRPL était relativement compressée : le problème a été signalé et reproduit le 22 septembre, le correctif a été développé et examiné du 22 au 23 septembre, fusionné dans la branche de version 3.4.1, et publié le 25 septembre. XRPL a rapporté que plus de 80 % des validateurs de la liste de nœuds uniques par défaut exécutaient la version protégée le jour même.
Le correctif du moteur de paiement a également pris effet directement avec la mise à niveau logicielle plutôt que d'attendre le processus normal d'activation des amendements. Cela a été possible parce que le rejet du débordement arithmétique a été traité comme la correction d'un comportement indéfini ou dangereux plutôt que comme l'introduction d'une nouvelle règle de transaction prévue.
Pour la sécurité de la blockchain, le moment de la divulgation fait partie de la défense. Publier l'exploit avant que les validateurs ne soient protégés aurait transformé une vulnérabilité théorique en instructions opérationnelles pour les attaquants. XRPL a donc divulgué les détails techniques après que la version corrigée avait déjà été propagée.
Risques et limites
L'incident est grave, mais plusieurs limites doivent rester claires.
- Aucun événement d'inflation confirmé : XRPL affirme n'avoir trouvé aucune preuve d'exploitation sur un réseau public.
- Aucun déclenchement accidentel : les paiements normaux et les carnets d'ordres réalistes n'atteignent pas les valeurs nécessaires.
- L'adoption du correctif est importante : les opérateurs de serveurs sont censés exécuter
xrpld 3.4.1ou une version plus récente. - Un correctif ne prouve pas une sécurité complète : d'autres anciennes hypothèses arithmétiques justifient encore des tests adversariaux.
- L'absence historique d'abus ne peut remplacer la vérification formelle : certaines classes de bugs sont trop inhabituelles pour émerger via l'activité normale du réseau.
Une autre limite est la certitude rétrospective. Les enquêteurs peuvent analyser l'historique du registre et les schémas d'exploitation connus, mais prouver qu'une vulnérabilité n'a jamais été utilisée est intrinsèquement différent de prouver mathématiquement qu'elle n'aurait pas pu l'être. La conclusion officielle est donc formulée de manière appropriée comme aucune preuve trouvée, plutôt que comme une affirmation absolue sur chaque état historique.
Point de vue de MEXC : l'offre fixe est une propriété de sécurité logicielle
La politique monétaire d'une blockchain n'est pas sécurisée par un chiffre d'offre écrit dans la documentation seule. Elle est sécurisée par le logiciel qui valide chaque changement de solde, chaque chemin de transaction et chaque état du registre.
L'incident XRPL illustre pourquoi cette distinction est importante. La règle prévue du protocole interdisait la création de nouveaux XRP, pourtant une faille dans l'arithmétique aurait théoriquement pu violer cette règle. Plus important encore, l'invariant défensif conçu pour détecter la création d'offre partageait initialement le même mode de défaillance.
Pour les réseaux blockchain matures, la sécurité doit donc aller au-delà du test du bon comportement des transactions normales. Les invariants indépendants, le fuzzing, les tests de limites adversariaux et les méthodes formelles deviennent de plus en plus importants précisément parce que les vulnérabilités les plus dommageables peuvent exister dans des chemins de code que les utilisateurs ordinaires ne touchent jamais.
La métrique à surveiller après cette divulgation n'est pas la réaction du prix du XRP. C'est de savoir si les processus de vérification élargis de XRPL trouvent et isolent systématiquement des classes similaires de risque latent du protocole avant les attaquants.
Le bug vieux d'une décennie était critique, pas un événement d'inflation XRP prouvé
La vulnérabilité du XRP Ledger mérite la description de « critique » car elle aurait théoriquement pu saper l'une des garanties les plus fondamentales de XRPL. Un paiement soigneusement conçu pourrait forcer un débordement arithmétique de 64 bits, créditer des centaines de propriétaires d'offres en XRP et ne facturer à l'acheteur qu'une fraction du montant total. Les soldes nouvellement créés étaient dépensables dans la reproduction de l'attaque par XRPL elle-même.
Mais la seconde moitié de l'histoire est tout aussi importante. XRPL n'a trouvé aucune preuve d'exploitation sur le réseau public, la transaction nécessitait des conditions de carnet d'ordres délibérément anormales, et la vulnérabilité a été corrigée dans xrpld 3.4.1 avant que les détails techniques ne soient divulgués publiquement.
L'incident ne doit donc pas être réécrit comme la preuve que l'offre de XRP a été historiquement gonflée. Son importance est plus structurelle. Il montre que même une blockchain à offre fixe dépend en fin de compte d'un logiciel appliquant correctement les contraintes monétaires dans des cas limites qui peuvent rester invisibles pendant des années.
Le principal enseignement de cette vulnérabilité du XRP Ledger concerne donc l'ingénierie des protocoles plutôt que les gros titres sur l'offre de jetons. Les invariants monétaires nécessitent une implémentation indépendante, le vieux code nécessite encore une revue adversariale, et le fonctionnement réussi du réseau pendant une décennie n'élimine pas la possibilité de défaillances cachées de conditions limites. Le bug n'a pas prouvé que des XRP avaient été surémis ; il a prouvé pourquoi l'intégrité de l'offre doit être continuellement vérifiée.
Sources
Divulgation officielle de vulnérabilité XRPL :
https://xrpl.org/es-es/blog/2026/vulnerabilitydisclosurereport-bug-20261009
Informations sur la version XRPL 3.4.1 :
https://xrpl.org/blog
Vous voulez obtenir les dernières informations de MEXC le plus rapidement possible ? Rejoignez dès maintenant notre groupe Telegram officiel !
Plateforme MEXC : Télécharger l'application | Trading sans frais | Acheter USDT maintenant Rejoignez la communauté MEXC : X (Twitter) | Telegram | Discord
Obtenir des informations : Académie pour débutants | Conditions d'utilisation | MEXC Blog | MEXC News
Vérification du compte : Comprendre le KYC | Comment effectuer le KYC
Avertissement sur les risques : Le contenu de cet article est fourni à titre de référence uniquement et ne constitue aucun conseil en investissement. Le marché des monnaies numériques est très volatil, veuillez prendre des décisions prudentes en fonction de votre propre situation.
