La Fondation XRP Ledger a confirmé le 26 février 2026 qu’une vulnérabilité critique dans la logique de validation des signatures de l’amendement Batch proposé a été identifiée et corrigée avant son activation, évitant ainsi une exploitation potentielle qui aurait permis aux attaquants d’exécuter des transactions non autorisées et de vider des fonds sans accès aux clés privées des victimes.
Découverte par l’ingénieur en sécurité Pranamya Keshkamat et l’outil de sécurité AI autonome Apex de Cantina le 19 février, la faille a été corrigée par une version d’urgence de rippled 3.1.1 le 23 février, sans risque pour les fonds puisque l’amendement était encore en phase de vote et n’avait jamais été activé sur le réseau principal.
Chronologie de la découverte et de la divulgation
Le 19 février 2026, une faille critique dans la logique de validation des signatures de l’amendement Batch pour le XRP Ledger a été identifiée. La vulnérabilité a été découverte par analyse statique du code rippled par Pranamya Keshkamat, ingénieur en sécurité chez Cantina, en collaboration avec l’outil AI autonome Apex de Cantina.
L’équipe de découverte a rapidement soumis un rapport de divulgation responsable à la Fondation XRPL, permettant aux équipes d’ingénierie de Ripple de valider la découverte avec une preuve de concept indépendante et une reproduction complète par tests unitaires. Les efforts de correction ont commencé le soir même.
Hari Mulackal, PDG de Cantina et Spearbit, a déclaré que « notre détecteur de bugs autonome, Apex, a trouvé cette faille critique », ajoutant que « si elle avait été exploitée, cela aurait été la plus grande attaque de sécurité en valeur monétaire au monde, avec près de 80 milliards de dollars en jeu », en référence à la capitalisation boursière de XRP.
Nature technique de la vulnérabilité
La vulnérabilité résidait dans la logique de validation des signatures de l’amendement Batch, une fonctionnalité proposée permettant l’exécution atomique jusqu’à huit transactions dans une seule opération par lot. Lorsqu’elle était activée, les transactions internes d’un lot étaient intentionnellement non signées, avec l’autorisation déléguée entièrement à la liste de signataires du lot extérieur.
La cause principale était une erreur de boucle critique dans la fonction responsable de la validation de ces signataires. Lorsqu’un validateur rencontrait un signataire dont le compte n’existait pas encore sur le registre et dont la clé de signature correspondait à leur propre compte — cas normal pour un nouveau compte — il déclarait immédiatement le succès et sortait, ignorant la validation des autres signataires.
Ce défaut créait une voie d’exploitation claire : un attaquant pouvait construire une transaction par lot contenant trois transactions internes — une créant un nouveau compte qu’il contrôle, une transaction simple depuis ce nouveau compte (le rendant un signataire requis), et un paiement depuis un compte victime vers l’attaquant. En fournissant deux entrées de signataires dans le lot — une légitime pour le nouveau compte et une falsifiée prétendant autoriser le compte victime mais signée avec la clé de l’attaquant — la validation s’arrêtait après la première entrée, sans valider la seconde, permettant au paiement de la victime d’être exécuté sans que ses clés soient impliquées.
Impact potentiel et mesures correctives
Si l’amendement Batch avait été activé avant la détection de la faille, un attaquant aurait pu voler des fonds en exécutant des transactions de paiement internes drainant les comptes victimes jusqu’à la réserve, modifier l’état du registre via des transactions non autorisées AccountSet, TrustSet ou AccountDelete, et potentiellement déstabiliser l’écosystème plus large par une perte de confiance dans XRPL.
Après confirmation de la vulnérabilité, les validateurs UNL ont été immédiatement contactés et invités à voter contre l’amendement Batch. La version d’urgence rippled 3.1.1 a été publiée le 23 février 2026, rendant Batch et fixBatchInnerSigs non supportés, empêchant leur vote par les validateurs ou leur activation sur le réseau.
Un amendement de remplacement corrigé, BatchV1_1, a été mis en œuvre avec une correction complète de la logique, supprimant la condition de sortie anticipée, ajoutant des garde-fous supplémentaires pour l’autorisation, et renforçant la vérification des signatures. Ce nouveau projet est actuellement en revue approfondie avant sa sortie, sans date précise.
Rôle émergent de l’IA en cybersécurité
Cette découverte met en lumière le rôle croissant de l’intelligence artificielle dans les applications de cybersécurité. Apex, l’outil AI autonome de Cantina, a identifié la vulnérabilité via une analyse statique du code, démontrant la capacité de l’IA à détecter des bugs subtils souvent négligés par les examinateurs humains.
Cet incident s’inscrit dans un contexte plus large de développement de la sécurité assistée par l’IA. Le 20 février, Anthropic a lancé Claude Code Security, un scanner de vulnérabilités en cybersécurité basé sur l’IA, que la société affirme « peut raisonner comme un chercheur en sécurité expérimenté ». L’émergence de ces outils pourrait marquer un tournant dans la détection et la correction des vulnérabilités des infrastructures critiques.
Réponse de la Fondation XRPL et mesures futures
La Fondation XRPL a présenté une feuille de route pour renforcer la sécurité, incluant l’intégration de pipelines d’audit de code assistés par l’IA comme étape standard, l’extension de la couverture d’analyse statique pour repérer les retours prématurés de succès dans les boucles de signataires, l’ajout de commentaires explicites et d’assertions invariantes pour documenter le comportement attendu des comptes non créés lors de la validation, et la revue de toutes les autres parties du code où des retours précoces de succès dans des boucles apparaissent pour vérifier l’absence de patterns similaires.
La fondation a également annoncé une réinitialisation programmée du devnet pour le 3 mars 2026, afin d’intégrer ces changements et d’éviter que des validateurs qui mettent à jour soient bloqués par l’amendement. La réinitialisation supprimera toutes les données du registre devnet, y compris comptes, transactions, soldes et autres enregistrements, avec tous les soldes remis à zéro et le numéro de bloc recommençant à un. Le mainnet, le testnet XRPL, Xahau et le testnet Hooks continueront leur fonctionnement normal sans interruption.
FAQ : Comprendre la vulnérabilité de l’amendement Batch sur XRPL
Q : Que devait faire l’amendement Batch sur XRP Ledger ?
A : L’amendement Batch était une fonctionnalité proposée permettant l’exécution atomique jusqu’à huit transactions dans une seule opération par lot. Il aurait permis aux développeurs de créer des applications avec fonctionnalités payantes, flux automatisés, et modèles de revenus directs sur la chaîne, en garantissant que plusieurs transactions s’exécutent ensemble, toutes réussissent ou échouent.
Q : Comment des attaquants auraient-ils pu exploiter cette vulnérabilité ?
A : En construisant une transaction par lot comprenant un paiement créant un nouveau compte, une transaction depuis ce compte, et un paiement depuis un compte victime, ils auraient pu exploiter une erreur où la validation s’arrêtait prématurément en rencontrant un signataire pour un compte inexistant, contournant ainsi la vérification des signatures sur le paiement de la victime et drainant des fonds sans posséder les clés privées de la victime.
Q : Pourquoi aucun argent n’a été perdu dans cet incident ?
A : L’amendement Batch était encore en phase de vote et n’avait pas été activé sur le mainnet lorsque la faille a été découverte. La Fondation XRPL a immédiatement conseillé aux validateurs de voter contre l’amendement et a publié une version d’urgence (rippled 3.1.1) le désactivant complètement, empêchant toute activation.
Q : Quel rôle l’IA a-t-elle joué dans la découverte de cette vulnérabilité ?
A : L’outil AI autonome Apex de Cantina a identifié la vulnérabilité via une analyse statique du code rippled. La découverte, combinée à l’analyse humaine, a permis une divulgation responsable et une correction avant toute activation de l’amendement, illustrant l’importance croissante des outils de cybersécurité basés sur l’IA.
