Le XRP Ledger (XRPL) a révélé deux vulnérabilités logicielles le 9 octobre 2026, dont un bug critique qui aurait pu permettre à des attaquants de créer de nouveaux XRP pouvant être dépensés. La seconde faille affectait la fonctionnalité de transactions par lots du réseau et aurait pu perturber la validation des transactions.
Selon le rapport officiel, le bug du moteur de paiement a été corrigé dans la version 3.4.1 de xrpld, publiée le 25 septembre. XRPL n’a trouvé aucun indice suggérant que la vulnérabilité ait été exploitée sur un réseau public.
Un bug d’XRPL aurait pu permettre de créer de nouveaux XRP
La vulnérabilité critique concernait la façon dont le moteur de paiement calculait la quantité de XRP requise pour effectuer des transactions portant sur plusieurs offres dans un carnet d’ordres. Le calcul pouvait subir un dépassement de capacité lorsque le montant total dépassait la valeur maximale prise en charge par le système. Le moteur de paiement pouvait alors facturer à l’acheteur moins de XRP que le montant crédité aux propriétaires des offres, créant ainsi de nouveaux XRP.
L’exploitation du bug nécessitait un carnet d’ordres préparé avec soin, contenant des centaines d’offres à des prix exceptionnellement élevés, puis une transaction de paiement spécifique. La vulnérabilité ne pouvait pas être déclenchée par des paiements ou des transactions ordinaires.
Un chercheur a signalé le problème dans le cadre du programme de chasse aux bugs du XRPL le 22 septembre 2026. L’équipe d’ingénierie de RippleX a reproduit le bug et confirmé que tout XRP créé par l’exploitation de cette faille pouvait être dépensé.
Le problème a été corrigé dans la version 3.4.1. Les développeurs ont ajouté des contrôles pour empêcher tout dépassement de capacité lors du calcul et renforcé les protections du système contre la création non autorisée de XRP.
Le deuxième bug affectait les transactions groupées du XRPL
La deuxième vulnérabilité concernait la fonctionnalité de transaction groupée du XRP Ledger, qui permet aux utilisateurs de soumettre plusieurs transactions ensemble. La faille permettait à une transaction faisant partie d’un lot d’utiliser un champ dont la structure était incorrecte. Le serveur pouvait tout de même accepter et traiter la transaction.
Cela créait un risque de désaccord entre les différentes versions du logiciel XRPL quant à la validité d’une transaction. De tels désaccords pouvaient empêcher les validateurs de parvenir à un consensus et interrompre la validation du registre.
Selon le rapport, le problème ne permettait pas aux attaquants de contourner les signatures de transaction ni de dérober directement des fonds.
Le XRPL a corrigé la faille au moyen de l’amendement fixBatchV1_2, qui impose aux transactions d’utiliser la structure appropriée. La fonctionnalité Batch n’avait pas été activée sur le réseau principal lorsque la vulnérabilité a été découverte. Le rapport n’a donc identifié aucun compte ni aucun fonds du réseau principal touché par ce bug.
Le XRPL active le correctif de sécurité de Batch
Les développeurs du XRPL et les opérateurs de validateurs ont retiré leur soutien à l’amendement Batch initial afin de réinitialiser son calendrier d’activation pendant que l’équipe préparait le correctif.
L’amendement corrigé a obtenu suffisamment de soutien et a été activé sur le réseau principal le 9 octobre 2026, le jour même de la publication du rapport sur la vulnérabilité.
Le rapport a également présenté une modification du processus de tests de sécurité. Le XRPL prévoit de tester à nouveau les vulnérabilités signalées sur les versions candidates afin de vérifier que les correctifs fonctionnent avant la publication des logiciels.
Ce que les détenteurs de XRP doivent savoir
Les deux vulnérabilités ont été corrigées, et le XRPL a indiqué n’avoir trouvé aucun indice d’exploitation du bug critique du moteur de paiement sur un réseau public. Le rapport n’établit pas que l’une ou l’autre faille ait entraîné une perte réelle de fonds ou une augmentation de l’offre de XRP. Le correctif du moteur de paiement est inclus dans la version 3.4.1 de xrpld, tandis que le problème lié à Batch a été corrigé au moyen de l’amendement fixBatchV1_2.
Le rapport ne demande pas aux détenteurs de XRP de déplacer leurs fonds ni de modifier leurs clés privées. La mise à niveau logicielle concerne les opérateurs de serveurs XRPL, qui doivent utiliser des versions compatibles pour rester synchronisés avec le réseau.