#xrpledgerpatchesxrpcreationbug
Et si un bug avait pu créer des XRP à partir de rien, sans être détecté pendant près de dix ans ? C’est la question au cœur de la dernière divulgation du XRPL. 🔍
Le 9 octobre, le XRP Ledger a révélé une vulnérabilité critique de son moteur de paiement, corrigée plusieurs semaines auparavant. Voici la chronologie :
22 septembre : les chercheurs Cayden Liao et Veria AI ont signalé une faille de dépassement d’entier dans le cadre du programme de récompenses pour la découverte de bugs.
25 septembre : xrpld 3.4.1 a été publié avec des contrôles contre les dépassements. Cette version a été déployée comme correctif d’urgence, sans le vote habituel des validateurs sur l’amendement, afin d’éviter que la faille reste exposée pendant une période de vote publique.
Le même jour : selon les informations rapportées, plus de 80 % des validateurs par défaut utilisaient la version corrigée.
D’après la divulgation, un attaquant aurait dû créer des centaines d’offres dont les prix auraient été soigneusement calculés, puis effectuer un seul paiement, pour potentiellement créer des XRP utilisables au-delà de l’offre de 100 milliards. RippleX a reproduit le problème sur un serveur autonome et affirme n’avoir trouvé aucune preuve d’exploitation. Un deuxième bug, de gravité moindre, affectait la fonctionnalité Batch, qui n’avait pas été activée sur le réseau principal.
Pourquoi est-ce important ? L’offre de XRP est fixe et préémise : toute création inattendue remettrait donc en question une hypothèse fondamentale. La rapidité de la réaction et la découverte grâce au programme de récompenses sont des signes rassurants pour la sécurité du réseau, tandis que la décision de contourner le processus de vote habituel pourrait soulever des questions de gouvernance.
Cela dit, « aucune preuve » ne signifie pas preuve d’absence, et la divulgation n’a eu lieu qu’après la correction. Quelle transparence les réseaux devraient-ils offrir dans ce genre de situation, et à quel moment ?
$MAGIC $LUMIA $XRP
Et si un bug avait pu créer des XRP à partir de rien, sans être détecté pendant près de dix ans ? C’est la question au cœur de la dernière divulgation du XRPL. 🔍
Le 9 octobre, le XRP Ledger a révélé une vulnérabilité critique de son moteur de paiement, corrigée plusieurs semaines auparavant. Voici la chronologie :
22 septembre : les chercheurs Cayden Liao et Veria AI ont signalé une faille de dépassement d’entier dans le cadre du programme de récompenses pour la découverte de bugs.
25 septembre : xrpld 3.4.1 a été publié avec des contrôles contre les dépassements. Cette version a été déployée comme correctif d’urgence, sans le vote habituel des validateurs sur l’amendement, afin d’éviter que la faille reste exposée pendant une période de vote publique.
Le même jour : selon les informations rapportées, plus de 80 % des validateurs par défaut utilisaient la version corrigée.
D’après la divulgation, un attaquant aurait dû créer des centaines d’offres dont les prix auraient été soigneusement calculés, puis effectuer un seul paiement, pour potentiellement créer des XRP utilisables au-delà de l’offre de 100 milliards. RippleX a reproduit le problème sur un serveur autonome et affirme n’avoir trouvé aucune preuve d’exploitation. Un deuxième bug, de gravité moindre, affectait la fonctionnalité Batch, qui n’avait pas été activée sur le réseau principal.
Pourquoi est-ce important ? L’offre de XRP est fixe et préémise : toute création inattendue remettrait donc en question une hypothèse fondamentale. La rapidité de la réaction et la découverte grâce au programme de récompenses sont des signes rassurants pour la sécurité du réseau, tandis que la décision de contourner le processus de vote habituel pourrait soulever des questions de gouvernance.
Cela dit, « aucune preuve » ne signifie pas preuve d’absence, et la divulgation n’a eu lieu qu’après la correction. Quelle transparence les réseaux devraient-ils offrir dans ce genre de situation, et à quel moment ?
$MAGIC $LUMIA $XRP