La sécurité du XRPL renforcée après que la faille de l'amendement par lots du xrpl a été bloquée avant le réseau principal

La Fondation XRPL a interrompu un problème grave lié à l’amendement batch du xrpl avant qu’il n’impacte le réseau principal, soulignant l’évolution de la posture de sécurité de la blockchain.

Faille critique détectée lors de la phase de vote

La Fondation XRPL a révélé qu’une vulnérabilité critique dans l’amendement Batch proposé a été identifiée et neutralisée avant l’activation sur le réseau principal. La faille est apparue alors que la modification était encore en phase de vote des validateurs, permettant aux développeurs de réagir avant tout impact en production.

Le problème a été découvert le 19 février 2026 par l’ingénieur en sécurité Pranamya Keshkamat, en collaboration avec l’outil autonome Apex de Cantina AI. Selon la fondation, aucune fonds utilisateur n’a jamais été en danger car l’amendement n’avait pas encore été activé sur le XRPL principal.

L’amendement, officiellement connu sous le nom de XLS-56, visait à introduire des transactions groupées sur le XRP Ledger. Il aurait permis de regrouper plusieurs transactions internes en un seul lot, améliorant ainsi l’efficacité et la coordination. Cependant, ces transactions internes étaient intentionnellement laissées non signées, avec l’autorisation déléguée à une transaction de lot extérieure listant les signataires.

Comment la faille de validation de signature fonctionnait

Selon le rapport post-mortem de la fondation, la vulnérabilité était liée à la logique de validation des signatures de la fonctionnalité Batch. De plus, le problème concernait une erreur de boucle dans la fonction de validation des signataires utilisée pour vérifier les autorisations de lot.

Lorsque le système rencontrait une entrée de signataire liée à un compte qui n’existait pas encore sur le ledger, il pouvait sortir prématurément de la boucle. Si la clé de signature correspondait au nouveau compte, le processus de validation était incorrectement marqué comme réussi. En conséquence, le logiciel sautait alors la vérification de toutes les autres entrées de signataires dans le lot.

Ce comportement ouvrait une voie à des transactions non autorisées. Un attaquant pouvait exécuter des opérations à partir de comptes victimes sans posséder leurs clés privées, car les vérifications de clés pour ces comptes pouvaient être contournées. Au moment de la découverte, l’amendement était encore en phase de vote des validateurs et restait désactivé sur le réseau principal.

La Fondation XRPL a insisté sur le fait que la proposition n’avait pas été activée et a réitéré : « L’amendement était en phase de vote et n’avait pas été activé sur le réseau principal ; aucun fonds n’était en danger. » Cette assurance était cruciale pour limiter l’inquiétude du marché et souligner l’importance des tests rigoureux avant activation.

Impact potentiel du bug de l’amendement batch

Le scénario d’exploitation rapporté nécessitait une transaction de lot soigneusement conçue. Un attaquant construirait un lot contenant trois opérations internes, orchestrées pour exploiter la logique défectueuse de validation des signataires.

Premièrement, une transaction interne créerait un nouveau compte entièrement contrôlé par l’attaquant. Deuxièmement, une autre transaction interne soumettrait un transfert simple ou une action depuis ce nouveau compte. Troisièmement, un paiement d’un compte victime choisi vers le compte de l’attaquant serait inclus, tentant de déplacer des fonds sans autorisation légitime.

Pour compléter la mise en place, l’attaquant fournirait deux entrées de signataires pour le lot. Une entrée serait valide pour le nouveau compte contrôlé par l’attaquant. La seconde prétendrait à tort autoriser des transactions pour le compte victime. Cependant, en raison du bug de sortie anticipée de la boucle, le système pourrait accepter le premier signataire et ne jamais valider correctement le second.

En conséquence, le paiement de la victime pourrait être exécuté sans signature valide, modifiant le ledger de manière non approuvée par la victime. La Fondation XRPL a averti que l’utilisation réussie de cette technique aurait pu permettre des transferts arbitraires de fonds et des modifications perturbatrices du ledger si elle avait été déployée à grande échelle.

De plus, l’organisation a souligné le risque pour la confiance plus large dans l’écosystème si une telle exploitation avait atteint le réseau principal. Hari Mulackal, PDG de Cantina et Spearbit, a commenté : « Notre chasseur de bugs autonome, Apex, a trouvé cette faille critique. » Les équipes d’ingénierie de Ripple ont ensuite reproduit le comportement avec une preuve de concept et effectué un test unitaire complet avant de corriger la faille.

Réponse d’urgence et mise à jour de rippled

Suite à la divulgation, les validateurs UNL de XRPL ont été rapidement conseillés de voter « Non » sur la proposition Batch. Cette coordination a permis d’éviter que l’amendement ne franchisse accidentellement le seuil d’activation pendant la période de correction.

Une version d’urgence du logiciel, rippled 3.1.1, a été publiée le 23 février 2026. Cette version marque explicitement que l’amendement Batch original et la modification fixBatchInnerSigs sont non supportés. Par conséquent, ils sont bloqués pour recevoir des votes de validateurs et ne peuvent pas être activés sur un réseau de production.

La version d’urgence ne comprend pas la logique corrigée finale. Elle agit plutôt comme une barrière de protection, garantissant que ni Batch ni fixBatchInnerSigs ne puissent atteindre l’activation dans leur forme défectueuse. Cependant, cette mesure immédiate a permis aux développeurs de gagner un temps précieux pour concevoir et examiner une solution plus sûre.

Un amendement corrigé nommé BatchV1_1 a été mis en œuvre en tant que successeur du design original. Cette mise à jour supprime la sortie anticipée dans la validation des signataires et renforce les vérifications sur tous les chemins d’autorisation. La fondation a confirmé que cette révision est toujours en cours d’examen, sans date de déploiement prévue.

Renforcer les pratiques de sécurité du XRPL

Suite à cet incident, la Fondation XRPL a défini des mesures de sécurité supplémentaires pour renforcer les flux de développement. De plus, elle prévoit d’étendre le rôle de l’IA dans la revue des changements de protocole afin de détecter plus tôt les erreurs logiques subtiles.

L’organisation souhaite augmenter l’utilisation des audits de code assistés par l’IA, en s’appuyant sur le succès des outils de Cantina AI et du système Apex dans ce cas. Elle élargira également l’analyse statique pour détecter spécifiquement des motifs comme des retours prématurés de succès dans les boucles, qui ont contribué à la faille dans la logique de validation du lot.

Cela dit, la fondation a souligné que l’épisode de l’amendement batch du xrpl montre l’importance de défenses en couches, incluant la revue humaine, l’analyse autonome et l’activation progressive. En combinant ces approches, les responsables cherchent à réduire le risque de vulnérabilités non détectées lors des futures mises à jour du protocole.

En fin de compte, la Fondation XRPL a insisté sur le fait que la faille critique a été corrigée avant l’activation sur le réseau principal et avant que des fonds ne soient compromis. La détection précoce, la réponse coordonnée des validateurs et la mise en place rapide de rippled ont permis d’éviter des transactions non autorisées et de préserver l’intégrité du réseau XRPL.