Le XRP Ledger révèle une faille critique pouvant permettre la création de nouveaux XRP

Le XRP Ledger (XRPL) a rendu publiques, le 9 octobre 2026, deux vulnérabilités logicielles, dont une faille critique susceptible de permettre à des attaquants de générer des XRP nouvellement créés et dépensables. Une seconde faille concernait la fonctionnalité de transactions groupées (Batch) et aurait pu perturber la validation des transactions. Selon le rapport officiel, le bug lié au moteur de paiement a été corrigé dans la version 3.4.1 de xrpld, publiée le 25 septembre. XRPL indique n'avoir constaté aucun indice d'exploitation de cette vulnérabilité sur un réseau public. Faille critique : un défaut de calcul dans le moteur de paiement La vulnérabilité critique touchait le calcul, par le moteur de paiement, de la quantité de XRP nécessaire pour exécuter des échanges au travers de plusieurs offres dans un carnet d'ordres. Lorsque le montant cumulé dépassait la valeur maximale prise en charge par le système, le calcul pouvait provoquer un dépassement (overflow). Dans ce scénario, le moteur de paiement pouvait débiter à l'acheteur moins de XRP que le montant crédité aux détenteurs d'offres, créant de fait de nouveaux XRP. L'exploitation supposait un carnet d'ordres soigneusement préparé, avec des centaines d'offres à des prix anormalement élevés, puis l'exécution d'une transaction de paiement spécifique. Le bug ne pouvait pas être déclenché via des paiements ou échanges ordinaires. Un chercheur a signalé le problème via le programme XRPL Bug Bounty le 22 septembre 2026. L'équipe d'ingénierie RippleX a reproduit le bug et confirmé que les XRP créés via cette faille pouvaient être dépensés. Le correctif a été intégré à la version 3.4.1 : des contrôles ont été ajoutés pour empêcher le dépassement de calcul et des garde-fous ont été renforcés afin d'éviter toute création non autorisée de XRP. Deuxième faille : risque de divergence de validation sur les transactions Batch La seconde vulnérabilité impliquait la fonctionnalité Batch, qui permet de soumettre plusieurs transactions en une seule fois. Une transaction à l'intérieur d'un lot pouvait inclure un champ structuré de manière incorrecte, tout en étant acceptée et traitée par le serveur. Cette situation introduisait un risque de désaccord entre différentes versions du logiciel XRPL quant à la validité d'une transaction. De tels écarts pouvaient empêcher les validateurs d'atteindre le consensus et interrompre la validation du registre. Le rapport précise que cette faille ne permettait pas de contourner les signatures de transaction ni de voler directement des fonds. XRPL a résolu le problème via l'amendement fixBatchV1_2, qui impose l'utilisation d'une structure correcte. La fonctionnalité Batch n'était pas activée sur le mainnet au moment de l'identification de la faille ; le rapport ne recense donc aucun compte ni fonds du mainnet affectés. Activation du correctif de sécurité Batch sur le mainnet Les développeurs d'XRPL et les opérateurs de validateurs ont retiré leur soutien à l'amendement Batch initial afin de réinitialiser son calendrier d'activation pendant la préparation du correctif. L'amendement corrigé a ensuite obtenu le soutien requis et a été activé sur le mainnet le 9 octobre 2026, le jour même de la publication du rapport. Le document annonce aussi une évolution des tests de sécurité : XRPL prévoit de retester les vulnérabilités signalées sur des versions candidates (release candidates) afin de confirmer l'efficacité des correctifs avant les mises en production. Ce que les détenteurs de XRP doivent retenir XRPL indique que les deux vulnérabilités ont été corrigées et qu'aucun élément ne suggère une exploitation du bug critique du moteur de paiement sur un réseau public. Le rapport ne conclut pas à une perte effective de fonds ni à une hausse avérée de l'offre de XRP. Le correctif du moteur de paiement est inclus dans xrpld 3.4.1, tandis que le problème Batch a été traité via l'amendement fixBatchV1_2. Aucune recommandation n'est formulée pour que les détenteurs de XRP déplacent leurs fonds ou modifient leurs clés privées. La mise à niveau concerne principalement les opérateurs de serveurs XRPL, qui doivent exécuter des versions compatibles afin de rester synchronisés avec le réseau.