XRPL invite les opérateurs de nœuds à mettre à jour vers xrpld 3.2.1 après l'inondation de manifestes de validateur

Titre : XRPL appelle à une mise à jour urgente des nœuds après un « flood de manifests » qui surcharge les ressources du réseau Vijay Khanna, directeur ingénierie de Ripple, a demandé le 2 août aux opérateurs de nœuds XRP Ledger d’installer immédiatement xrpld v3.2.1 après que des développeurs aient détecté un « flood de manifests » de validateurs le 31 juillet. Ce correctif rapide limite la manière dont les nœuds traitent, stockent et partagent les données de manifests provenant d’identités de validateurs inconnues — empêchant les attaquants d’épuiser la mémoire, le stockage, la bande passante et le processeur des nœuds — tout en préservant le fonctionnement normal du ledger pendant le déploiement du correctif. Ce qui s’est passé - Le 31 juillet, les développeurs ont observé une augmentation soudaine de manifests de validateurs provenant d’identités inconnues. Bien que le ledger ait continué à se fermer normalement, cet événement a mis sous pression les ressources des nœuds et les communications peer-to-peer. - Aucune preuve publique n’indique de fonds volés, de transactions modifiées ou d’échec de consensus. Les développeurs n’ont pas émis de CVE ni publié d’estimation de pertes financières liées à cet incident. - XRPL Operations a annoncé qu’un post-mortem technique suivra ; au 2 août, l’origine du flood, le volume total et l’impact précis sur les ressources restent non divulgués. Pourquoi les manifests de validateurs sont importants - Les manifests de validateurs sont des enregistrements signés cryptographiquement qui lient l’identité maîtresse stable d’un validateur aux clés temporaires utilisées pour les messages de validation quotidiens. Lorsque les opérateurs changent les clés temporaires, ils publient un nouveau manifest signé par la clé maîtresse afin que les pairs puissent vérifier le changement. - Avant le correctif, xrpld pouvait accepter, mettre en cache et rebroadcast des manifests correctement structurés pour des clés de validateurs qu’il ne reconnaissait pas. Un attaquant pouvait exploiter ce comportement en créant de nombreuses identités inconnues et en forçant les pairs à gaspiller de la mémoire, du stockage, de la bande passante et des ressources de traitement pour gérer ces données. Le dépôt de code décrit ce problème comme une abus de propagation de manifests. Contenu de xrpld 3.2.1 - La version officielle xrpld 3.2.1 (datée du 31 juillet ; signée et publiée début 1er août) contient six commits répartis sur 13 fichiers. Quatre commits limitent directement le traitement des manifests non fiables. Les principales protections : - Rejet précoce des manifests trop volumineux avant leur décodage complet, réduisant le travail CPU par objet malveillant. - Limites sur le nombre de manifests non fiables autorisés dans un seul message réseau — appliquées à la réception et lors de la préparation des messages pour les pairs. Les lots trop volumineux sont supprimés sans déconnecter les pairs non mis à jour, facilitant la compatibilité du déploiement. - Limite par nœud sur le nombre d’identités de validateurs inconnues mises en cache en mémoire, plafonnée à 100. Une fois pleine, les nouveaux manifests non listés sont rejetés, tandis que les validateurs approuvés et mémorisés continuent d’être traités. - Modifications apportées à la manière dont les informations des manifests non fiables sont conservées et diffusées, ciblant la diffusion entre pairs non listés plutôt que les manifests provenant de validateurs configurés ou approuvés. Cela préserve la rotation légitime des clés des validateurs tout en bloquant la croissance incontrôlée du cache. Conseils aux opérateurs et notes de déploiement - Khanna a conseillé aux validateurs et opérateurs d’infrastructure de mettre à jour vers v3.2.1 « dès que possible ». Le processus recommandé : effectuer la mise à jour logicielle normale, attendre une à deux minutes pour confirmer que xrpld fonctionne, puis redémarrer à nouveau le service. Ce second redémarrage aide à purger tout manifest inconnu conservé en mémoire avant le correctif. - Les opérateurs doivent également vérifier que leurs systèmes font confiance à la clé GPG actuelle de signature des paquets de Ripple. Ripple a fait pivoter cette clé le 18 février ; les nœuds qui n’ont pas approuvé la nouvelle clé peuvent ne pas recevoir de mises à jour automatiques. - Cette mise à jour s’adresse aux opérateurs d’infrastructure (plateformes d’échange, custodians, back-ends wallet, fournisseurs de données et entreprises exécutant des serveurs XRPL). Les détenteurs ordinaires d’XRP n’ont pas besoin de déplacer leurs fonds, de faire pivoter leurs clés ou d’effectuer toute action. Contexte et prochaines étapes - Ce correctif suit le déploiement plus large de xrpld v3.2.0 (15 juin), qui a renommé le serveur de référence de rippled en xrpld et exigé que les opérateurs mettent à jour leurs configurations. L’adoption de v3.2.0 a été plus rapide chez les validateurs que dans le réseau des nœuds plus large ; le flood de manifests donne aux opérateurs restants une autre raison forte de passer à v3.2.1. - XRPL Operations a promis un post-mortem technique qui détaillera quand l’activité a été détectée pour la première fois, si certains nœuds sont devenus indisponibles, le volume des manifests et la rapidité avec laquelle les opérateurs ont adopté le correctif. Jusqu’à la publication de ce rapport, les détails confirmés restent limités aux corrections apportées par v3.2.1 et à la demande d’upgrade et de redémarrage pour les opérateurs. Conclusion Si vous gérez une infrastructure XRPL, traitez cela comme une urgence : mettez à jour vers xrpld 3.2.1 et suivez la recommandation de redémarrage en deux étapes pour effacer tout manifest non fiable conservé. Pour la communauté XRPL plus large, cet incident semble avoir été une tentative d’épuisement des ressources plutôt qu’une compromission du protocole — mais le post-mortem à venir sera essentiel pour confirmer l’étendue complète.