Le mécanisme de consensus du XRPL comporte un défaut mortel, les attaquants peuvent paralyser le réseau de validation - Déjà corrigé

Société de recherche en sécurité Common Prefix a précédemment signalé à l’équipe Ripple deux vulnérabilités graves de XRP Ledger (XRPL), toutes deux liées à la logique de consensus du traitement des transactions par les nœuds de validation. Si la liste de nœuds uniques (UNL) est compromise, un attaquant peut envoyer des messages malveillants, provoquant la chute en chaîne des nœuds de validation. Les correctifs ont été intégrés à la version rippled 3.0.0.

Noyau du risque de la vulnérabilité : un seul nœud compromis peut affecter tout le réseau

Le mécanisme de consensus XRPL exige que les nœuds de validation s’accordent sur un ensemble de transactions, en proposant des transactions non traitées connues, et en échangeant des messages pour établir un consensus final. La cause profonde des deux vulnérabilités réside dans une faille dans la logique de traitement des « transactions contestées » (différences entre les ensembles de transactions des différents nœuds).

Les conditions d’attaque incluent l’intrusion dans l’un des environ 35 nœuds de validation de la UNL. Bien que ces nœuds soient généralement dissimulés derrière des nœuds proxy et communiquent uniquement avec eux, rendant l’intrusion plus difficile, le chercheur Nikolaos Kamarinakis de Common Prefix indique que ce n’est pas impossible. En cas de succès, l’attaquant peut déployer un outil rippled modifié pour envoyer en continu des messages malveillants aux autres nœuds, jusqu’à ce que le nœud compromis soit retiré de la UNL.

Mécanismes techniques des deux vulnérabilités et solutions de correction

Vulnérabilité 1 — Comparaison de transactions (Comparing Transactions) : Le nœud compromis affirme qu’une transaction existe dans un SHAMap alors qu’elle n’est pas présente sur le nœud concerné. Lorsqu’un autre nœud tente de rechercher cette transaction avec un ID invalide, il plante immédiatement.

Correction 1 : Ajout d’une étape de vérification pour confirmer que la transaction existe réellement sur le nœud proposé, empêchant la défaillance déclenchée par un ID invalide.

Vulnérabilité 2 — Relais de transactions (Relaying Transactions) : Le nœud compromis envoie un ensemble de transactions malveillantes contenant des hachages arbitraires. Les autres nœuds les identifient comme des transactions contestées et tentent de les relayer, ce qui provoque un crash lors de la vérification de faux transactions en raison de données invalides.

Correction 2 : Ajout d’un mécanisme try-catch pour capturer les exceptions causées par des données malveillantes, empêchant la propagation du crash.

L’équipe Ripple a reproduit avec succès ces deux vulnérabilités dans un réseau de test isolé en utilisant un programme de vérification indépendant, et a confirmé qu’après application des correctifs, les nœuds ne se crashent plus lorsqu’ils reçoivent des messages malveillants.

Confirmation des correctifs et feuille de route pour le renforcement de la sécurité XRPL

Les correctifs pour ces deux vulnérabilités ont été intégrés à rippled 3.0.0. Ripple a confirmé que, dans un environnement de test, les nœuds corrigés restent stables face aux mêmes vecteurs d’attaque.

Ripple a également annoncé une feuille de route pour renforcer la sécurité XRPL, comprenant l’extension des audits de sécurité pour détecter en amont les problèmes dans le code non publié, l’introduction de l’intelligence artificielle pour la revue de code systématique, l’organisation de hackathons de sécurité, et l’augmentation des récompenses pour la découverte de vulnérabilités afin d’inciter la communauté externe à signaler proactivement les failles.

Ripple a officiellement remercié Common Prefix dans son rapport, saluant leur divulgation responsable des vulnérabilités et leur soutien technique durant la période de correction.

Questions fréquentes

Quelle est la difficulté réelle d’attaque sur ces deux vulnérabilités XRPL ?

L’attaque nécessite d’infiltrer l’un des environ 35 nœuds de validation de la UNL. Ces nœuds sont généralement dissimulés derrière des proxy et communiquent uniquement avec eux, limitant la surface d’attaque. Cependant, les chercheurs en sécurité soulignent que ce n’est pas impossible, rendant la correction préalable essentielle.

Que doivent faire les opérateurs de nœuds XRPL ?

Tous les opérateurs utilisant rippled 2.6.2 ou une version antérieure doivent mettre à jour rapidement vers rippled 3.0.0 pour bénéficier d’une protection complète contre ces vulnérabilités. Les versions antérieures présentent un risque de crash en chaîne si un nœud de validation de la UNL est compromis.

Quelle signification ces vulnérabilités ont-elles pour la sécurité à long terme de XRPL ?

Ce cas illustre un processus de divulgation responsable : Common Prefix a signalé en privé en juin 2025, Ripple a corrigé dans rippled 3.0.0, puis a publié en mars 2026. La feuille de route de sécurité, incluant l’IA et l’augmentation des récompenses, montre l’engagement continu pour une sécurité proactive.