Los desarrolladores de XRP Ledger han revelado una vulnerabilidad crítica que podría haber permitido a un atacante crear XRP gastable de la nada, eludiendo las salvaguardas diseñadas para evitar que el suministro de la criptomoneda aumentara.

La falla estaba en el motor de pagos del ledger y fue reportada a través del programa XRPL Bug Bounty el 22 de septiembre por Cayden Liao y Veria AI. Los ingenieros de RippleX reprodujeron el exploit en un servidor independiente, confirmaron que el XRP recién creado podía gastarse en un pago posterior y elevaron su severidad de mayor a crítica. El manejo sigue la práctica estándar de divulgación coordinada: los reportes de recompensas llegan de manera privada a los mantenedores, y los detalles técnicos completos se publican solo después de que se haya lanzado una corrección.

Según el informe de divulgación publicado en el blog oficial de XRPL, no hay evidencia de que la vulnerabilidad haya sido explotada en ninguna red pública de XRP Ledger. Los desarrolladores prepararon una corrección de manera privada y lanzaron xrpld versión 3.4.1 el 25 de septiembre, dos días después de que el parche se fusionara en la rama de lanzamiento de emergencia.

El desbordamiento de enteros podía eludir los controles de suministro de XRP

La falla existía en el motor de pagos de XRP Ledger desde aproximadamente 2015 e involucraba aritmética de enteros de 64 bits sin verificación cuando un pago consumía múltiples ofertas del libro de órdenes de la red.

Un número de 64 bits llega como máximo a cerca de 18.4 quintillones, y los desbordamientos en ese tipo de aritmética de ancho fijo son una clase de errores conocida en software de ledgers: en 2010, un desbordamiento de enteros en las verificaciones de valor de Bitcoin creó brevemente alrededor de 184 mil millones de BTC antes de que los desarrolladores lo corrigieran en cuestión de horas.

Un atacante podía crear cientos de cuentas y colocar ofertas especialmente construidas que vendieran pequeñas cantidades de otro token por cantidades extremadamente grandes de XRP. Un solo pago que consumiera esas ofertas podía llevar el total calculado más allá del valor máximo que el entero soporta. En lugar de rechazar la transacción, el total daba la vuelta a un número pequeño. Cada propietario de oferta aún podía recibir la cantidad completa de XRP especificada en su oferta, mientras que al comprador solo se le cobraba el valor mucho menor resultante del desbordamiento.

El ataque requería solo unos pocos cientos de XRP para las reservas de cuentas y ofertas, gran parte de los cuales podía recuperarse posteriormente, además de las tarifas ordinarias de transacción.

La verificación integrada de XRPL, diseñada para garantizar que las transacciones no puedan crear XRP, no habría detenido el exploit. El invariante usaba el mismo tipo de aritmética y podía desbordarse de la misma manera, mientras que un límite de saldo por cuenta podía eludirse distribuyendo el XRP recién creado entre cientos de cuentas. La fragilidad era importante debido a cómo funciona el suministro de XRP: los 100 mil millones de tokens se crearon en el lanzamiento del ledger, las tarifas de transacción queman XRP en lugar de acuñarlo, y las verificaciones de invariantes son la garantía de que ninguna ruta de pago pueda aumentar el total. La falla se limitaba a transacciones deliberadamente construidas y no podía activarse mediante pagos normales actividad de trading.

Los validadores migraron a 3.4.1 en cuestión de horas

Los desarrolladores optaron por desplegar la corrección del desbordamiento de XRP de inmediato en lugar de someterla al proceso normal de enmiendas de XRPL, que generalmente requiere más del 80% de apoyo de los validadores durante dos semanas antes de que un cambio de protocolo se active. Dejar la vulnerabilidad expuesta durante ese período habría creado una ventana en la que el método de ataque fuera conocido públicamente pero aún utilizable.

Más del 80% de los validadores en la Unique Node List predeterminada se habían actualizado a 3.4.1 el 25 de septiembre, el mismo día en que se lanzó la versión de emergencia. El lapso de tres días desde el reporte privado hasta la adopción mayoritaria de los validadores mostró la ruta de lanzamiento de emergencia del ledger funcionando de principio a fin.

La versión 3.4.1 ahora rechaza los pagos cuando el total de ofertas se desbordaría y usa un contador más amplio para el invariante de creación de XRP. También se endurecieron cálculos adicionales de saldos contra fallas aritméticas similares.

El incidente sigue a un compromiso no relacionado en la cadena de suministro de xrpl.js descubierto en 2025, que afectó lanzamientos maliciosos de paquetes de JavaScript en lugar del protocolo de XRP Ledger en sí. El sistema de enmiendas de XRPL también se está utilizando para funcionalidades más recientes, como el propuesto XRPL Lending Protocol, donde la aprobación de los validadores determina si el nuevo comportamiento de las transacciones se activa.

La falla de desbordamiento no alteró el suministro existente de XRP. No se ha identificado XRP no autorizado, y los operadores de servidores ahora deben ejecutar xrpld 3.4.1 o posterior para mantenerse sincronizados con la red. Lo que permanece observable es operativo: los rezagados en versiones anteriores migrando a 3.4.1 o posterior, y propuestas como el XRPL Lending Protocol continuando por la vía estándar de enmiendas que esta corrección omitió.

Fuente: XRP Ledger Patches Decade-Old Flaw That Could Create Spendable XRP — Crypto Adventure