El XRP Ledger corrigió una vulnerabilidad que, bajo una secuencia específica de operaciones, podía generar XRP sin descontar la misma cantidad de otra cuenta. La falla afectaba una regla esencial de la red: su oferta inicial de 100.000 millones de unidades no debería aumentar mediante transacciones ordinarias. Los desarrolladores afirman que no encontraron indicios de explotación en la red pública.
El problema, que probablemente existía desde 2015, fue señalado el 22 de septiembre por el investigador Cayden Liao y Veria AI, según informó CoinDesk. RippleX lo reprodujo en un entorno aislado y confirmó que los XRP generados podían gastarse en una segunda transacción; el informe técnico publicado después detalla la respuesta coordinada de los validadores.
Cómo un cálculo podía alterar la oferta de XRP
La vulnerabilidad estaba en el motor de pagos que interactúa con el mercado descentralizado integrado en la red. Un atacante podía preparar numerosas ofertas para vender cantidades diminutas de otros activos a cambio de grandes sumas de XRP y, después, activar su ejecución con un pago especialmente diseñado. Al sumar los importes, una operación aritmética superaba el límite permitido por el tipo de número usado por el programa.
Cuando ocurre ese desbordamiento, el contador puede volver a un valor pequeño. En este caso, las cuentas que habían publicado las ofertas recibirían el total de XRP previsto, mientras que la cuenta compradora pagaría una fracción. La diferencia equivaldría a XRP creados indebidamente y, de acuerdo con la prueba realizada, esos fondos podían transferirse posteriormente.
El control de seguridad destinado a impedir la creación de XRP dependía de un cálculo afectado por el mismo error, por lo que tampoco detectaba la discrepancia. Además, repartir las ofertas entre muchas cuentas permitía esquivar el límite aplicado a cada una. No bastaba una operación casual: el escenario exigía construir y coordinar una serie concreta de ofertas y pagos.
Una actualización de emergencia para los validadores
La corrección llegó con la versión 3.4.1 del software xrpld el 25 de septiembre. Los cambios incorporaron comprobaciones adicionales frente al desbordamiento y ampliaron el tipo de número empleado para verificar que ninguna transacción aumenta la oferta.
Según la divulgación, más del 80 % de los validadores de la lista predeterminada de confianza habían actualizado ese mismo día, momento en el que la red quedó protegida frente a este vector.
Los responsables optaron por aplicar la protección al instalar el programa, sin esperar al mecanismo habitual de activación de enmiendas. Ese procedimiento habría hecho pública la solución durante semanas antes de que entrara en vigor, una ventana que podía facilitar la búsqueda de un ataque.
La decisión aceleró el cierre del fallo, aunque obligó a coordinar versiones distintas del software durante la transición.
Alcance confirmado y preguntas abiertas
La gravedad potencial no significa que se hayan creado miles de millones de dólares en XRP. La cifra describe lo que un atacante podría haber obtenido si hubiera explotado la falla a gran escala. La evidencia presentada hasta ahora corresponde a un servidor de pruebas, y los equipos que investigaron el caso dicen no haber encontrado señales de uso malicioso en la cadena pública.
El episodio muestra por qué los controles de emisión deben utilizar cálculos independientes de aquellos que validan una operación: si ambos comparten el mismo defecto, pueden coincidir en un resultado incorrecto. Para los usuarios, la distinción clave es entre una vulnerabilidad demostrada y una emisión efectivamente detectada. Por ahora, la primera está documentada y corregida; la segunda no ha sido observada.
