Los desarrolladores de XRP Ledger han divulgado un error crítico de desbordamiento que pudo haber permitido a un atacante crear XRP de la nada, excediendo el límite fijo de la red de 100 mil millones de tokens. La falla afectaba a xrpld, el software de servidor central del ledger, en las versiones 3.4.0 y anteriores. Fue corregido discretamente en septiembre y hecho público el 9 de octubre de 2026. Los investigadores no encontraron evidencia de que haya sido explotado en una red pública.

Cómo funcionaba el error

La vulnerabilidad radicaba en la forma en que xrpld contabilizaba los montos de los pagos. Cuando un solo pago tomaba liquidez de múltiples ofertas en el libro de órdenes descentralizado, el software usaba un entero de 64 bits para llevar un total acumulado del XRP involucrado. Si ese total superaba el número más grande que el entero podía almacenar, se desbordaba a un valor mucho menor que la realidad. Errores de desbordamiento como este son una categoría clásica de fallas de software —aritmética que excede el tamaño fijo de la variable que almacena el resultado— y se encuentran entre los primeros riesgos que los revisores buscan en código que mueve dinero.

Un atacante podría haber explotado esa brecha para gastar XRP que no existía. Debido a que los saldos inflados estaban dispersos entre muchas cuentas, los controles de seguridad existentes del ledger no lograron señalar la discrepancia, permitiendo que los libros parecieran equilibrados mientras el suministro real aumentaba silenciosamente.

El costo de ejecutar tal ataque era sorprendentemente bajo. Según la divulgación, el exploit requería ofertas especialmente diseñadas de cientos de cuentas, con un costo de solo unos pocos cientos de XRP en reservas y comisiones, la mayoría de los cuales habrían sido recuperables. La cantidad de XRP que pudo haberse acuñado en una sola transacción podría haber excedido el suministro total del token.

Una corrección silenciosa, luego una divulgación pública

La vulnerabilidad fue reportada el 22 de septiembre de 2026 por el investigador Cayden Liao a través del programa XRPL Bug Bounty. RippleX, el brazo desarrollo de Ripple, confirmó el problema y reprodujo el ataque en un servidor independiente, verificando que el XRP excedente podía gastarse en transacciones posteriores.

Tres días después del reporte, el 25 de septiembre de 2026, se lanzó una versión de emergencia: xrpld 3.4.1. La corrección también omitió el proceso habitual de enmiendas del ledger, bajo el cual los cambios en las reglas de la red normalmente entran en vigor solo después de un procedimiento de votación de validadores. Este parche se implementó de inmediato en su lugar.

La divulgación pública siguió el 9 de octubre, aproximadamente dos semanas después de que se lanzara el software corregido. El equipo reportó ninguna pérdida de fondos, ninguna clave comprometida y ningún problema de consenso relacionado con el error. Esta secuencia sigue la divulgación coordinada de vulnerabilidades, la práctica estándar en seguridad de software de lanzar correcciones antes de publicar los detalles, dando a los operadores una ventana para actualizar antes de que la información que podría guiar un ataque se haga pública. El programa XRPL Bug Bounty que produjo el reporte es parte del mismo mecanismo, uno que paga a investigadores independientes por revelar fallas de manera privada en lugar de explotarlas o divulgarlas por su cuenta.

Una década oculta

Se cree que la falla existía desde que el motor de pagos fue construido por primera vez, alrededor de 2015, lo que significa que el código procesó pagos durante años con un desbordamiento latente en su interior. Los errores capaces de inflar el activo nativo de una cadena son raros, pero no sin precedentes: en 2018, los desarrolladores de Bitcoin Core lanzaron un parche de emergencia para una falla que igualmente pudo haber permitido a un atacante crear bitcoin fuera de las reglas de emisión de la red.

Qué significa esto para los holders de XRP y el ledger

Para los holders de XRP, la conclusión inmediata es tranquilizadora: no hay evidencia de que el error haya sido explotado, y la integridad del suministro del token parece intacta. El episodio también es un recordatorio de que un límite fijo de suministro, en última instancia, es aplicado por código, y solo es tan confiable como ese código.

La decisión de omitir el proceso de enmiendas, sin embargo, merece atención. Un camino conocido hacia la creación ilimitada de XRP no es algo que pueda esperar una votación de gobernanza, pero los parches de emergencia que omiten los procedimientos normales depositan una confianza significativa en el equipo central de desarrollo. En este caso, la seguridad de la red dependió de que los validadores y operadores de nodos actualizaran rápidamente.

Los operadores de nodos que aún ejecutan xrpld 3.4.0 o anterior son el público más directo de esta noticia. La versión corregida, 3.4.1, está disponible desde el 25 de septiembre, y cualquiera que no haya actualizado está ejecutando software con una falla que rompe el suministro y que ahora está documentada públicamente.

Fuente: CryptoBriefing