Community Trust ScoreVérifié
XRP Ledger a déployé une mise à jour d’urgence le 31 juillet. La mise à jour, xrpld 3.2.1, est survenue après que les nœuds du réseau ont été touchés par une attaque de type « manifest flood » — une attaque discrète et épuisante en ressources qui ne vole pas de fonds mais peut discrètement paralyser l’infrastructure si elle n’est pas détectée assez rapidement.
Le directeur de l’ingénierie de Ripple, Vijay Khanna, a appelé les opérateurs de nœuds à effectuer la mise à niveau immédiatement, avec le déploiement se déroulant les 1er et 2 août. Aucun fonds n’a été perdu. Le consensus du réseau est resté intact. Mais les nœuds non corrigés restent exposés jusqu’à ce que les opérateurs terminent un processus de mise à niveau en deux étapes — et ce n’est pas un détail négligeable.
Comment le « Manifest Flood » a réellement fonctionné
L’attaque a exploité une faille dans la gestion des manifestes de validateurs par les nœuds XRPL. Avant le correctif, les nœuds acceptaient, mettaient en cache et rediffusaient des manifestes liés à des clés de validateurs inconnues — sans aucune limite de volume. Pas de plafond. Les attaquants pouvaient inonder le réseau de manifestes inutiles et voir les nœuds consommer de la mémoire, de l’espace disque et de la bande passante pour traiter des données sans valeur.
Le traitement des transactions lui-même n’a pas été affecté. Le registre a continué à fonctionner. Mais l’infrastructure sous-jacente ? Elle se faisait discrètement dévorer par des données inutiles. L’équipe de développement a identifié le problème dans la logique de gestion des manifestes, bien que les détails complets de l’exploitation n’aient pas encore été rendus publics. Probablement sage — inutile de fournir une feuille de route à quiconque.
Le correctif 3.2.1 introduit quatre protections spécifiques dans la gestion des manifestes. Les manifestes surdimensionnés sont rejetés avant même le début du décodage. Les lots de manifestes par message réseau sont désormais limités. La quantité de données de manifestes partagées avec de nouveaux pairs est limitée. Et le cache pour les manifestes de clés inconnues est strictement limité à 100 entrées. De plus, les manifestes de validateurs inconnus ne sont plus écrits sur le disque.
La mise à niveau en deux étapes que les opérateurs ne peuvent pas ignorer
Installer la mise à jour n’est pas une solution en un clic. Les opérateurs doivent installer la version 3.2.1, laisser le serveur fonctionner quelques minutes, puis effectuer un deuxième redémarrage pour éliminer toute donnée pré-correctif encore présente sur le système. Si cette deuxième étape est ignorée, des données résiduelles du « flood » pourraient encore subsister. On ne sait pas exactement combien d’opérateurs ont terminé le processus complet jusqu’à présent, mais l’urgence est réelle.
Il y a une autre complication. Les opérateurs doivent s’assurer que leurs systèmes font confiance à la clé de signature GPG actuelle de Ripple — celle mise à jour le 18 février 2026. Si cette clé n’est pas à jour, la mise à niveau peut échouer silencieusement. Pas de message d’erreur, pas d’avertissement, juste un système qui pense être corrigé mais ne l’est pas. C’est le genre de chose qui empêche les équipes d’infrastructure de dormir la nuit.
La lente adoption de xrpld v3.2.0, publiée le 15 juin, a aggravé la situation. Beaucoup d’opérateurs n’avaient même pas encore migré vers cette version lorsque l’attaque a eu lieu. Ainsi, l’écart entre l’état actuel du réseau et là où il doit être est plus large qu’il ne devrait l’être.
Les bourses, les dépositaires, les back-ends de portefeuilles, les fournisseurs de données, les entreprises exploitant leurs propres serveurs XRPL — tous doivent agir. Les détenteurs réguliers de XRP n’ont rien à faire. Mais ceux qui gèrent l’infrastructure ? Ils sont sous pression.
Pourquoi les enjeux sont plus élevés maintenant
XRPL a ajouté plus de 490 000 nouveaux comptes au cours du premier semestre 2026 seulement. Le nombre total de comptes sur le réseau a dépassé les 8,4 millions. Ce n’est plus un registre de niche — c’est un réseau qui porte un poids institutionnel sérieux, y compris des initiatives comme le fonds de liquidité tokenisé d’Aviva. Plus d’utilisateurs, plus de transactions, plus de raisons pour les acteurs malveillants de chercher des faiblesses.
Et c’est là toute la tension. Les mécanismes de consensus blockchain peuvent être solides comme le roc tandis que l’infrastructure de soutien — la gestion des manifestes, le partage des données entre pairs, la logique de mise en cache — est exploitée par une porte dérobée. C’est essentiellement un angle de déni de service. Pas glamour, pas le genre de piratage qui fait la une, mais suffisamment efficace pour dégrader les performances des nœuds et ébranler les opérateurs qui ne surveillent pas attentivement.
L’équipe de développement a annoncé qu’un compte rendu technique est à venir. Cela donnera probablement une image plus claire de la façon dont l’attaque s’est déroulée et quelles défenses supplémentaires pourraient suivre. Pour l’instant, le correctif est la réponse, et la demande est simple : mettre à jour, redémarrer deux fois, vérifier la clé GPG.
Les opérateurs de nœuds qui ne sont pas passés à la version 3.2.1 continuent d’exploiter une infrastructure exposée sur un réseau qui vient de dépasser les 8,4 millions de comptes.
Hub : Prix, actualités et analyses de XRP
Hub: XRP : prix, actualités et analyse
Questions Fréquentes
Qu’a corrigé le correctif xrpld 3.2.1 sur le XRP Ledger ?
La mise à jour a corrigé une vulnérabilité de type « manifest flood » où les nœuds XRPL acceptaient et mettaient en cache un nombre illimité de manifestes de validateurs à partir de clés inconnues, épuisant la mémoire, l’espace disque et la bande passante. Quatre nouvelles protections ont été ajoutées, y compris une limite de 100 entrées sur les caches de manifestes de clés inconnues et le rejet des manifestes surdimensionnés avant le décodage.
Qui doit effectuer la mise à niveau après l’attaque « manifest flood » du XRP Ledger ?
Les bourses, les dépositaires, les back-ends de portefeuilles, les fournisseurs de données et toute entreprise exploitant un serveur XRPL doivent compléter la mise à niveau en deux étapes vers xrpld 3.2.1. Les détenteurs ordinaires de XRP n’ont pas besoin de prendre de mesures.
