XRP Ledger publicó el 9 de octubre de 2026 un informe de vulnerabilidad que describe un error de overflow, o desbordamiento aritmético, en el motor de pagos de XRP. Según ese documento, el hallazgo fue reportado el 22 de septiembre de 2026 mediante el programa XRPL Bug Bounty y afectaba a xrpld 3.4.0 y versiones anteriores. El problema importaba porque un atacante podía construir ofertas y un pago de tal forma que el software aceptara XRP creado de la nada. La corrección ya se había lanzado el 25 de septiembre en xrpld 3.4.1, y ese mismo día más del 80% de los validadores de la default UNL ya ejecutaban esa versión o una posterior.
El caso toca una propiedad central de XRP: que las reglas del software no permitan emitir más unidades por fuera de lo previsto. Según los mantenedores, no encontraron evidencia de explotación en redes públicas, lo que reduce el daño material conocido. Aun así, la misma investigación sostiene que el bug estaba presente desde 2015.
Cómo funcionaba el error en los pagos con libro de órdenes
De acuerdo con XRP Ledger, el fallo aparecía cuando un pago consumía muchas ofertas del libro de órdenes incorporado en la red, es decir, la lista de ofertas pendientes para intercambiar activos dentro del propio ledger. En ese punto, la suma de montos podía exceder el máximo de un entero de 64 bits, un tipo de contador numérico usado por el software. Al sobrepasar ese límite, el total podía volver a un número pequeño. El resultado sería que el comprador pagara casi nada mientras los vendedores recibían el monto completo.
El problema no terminaba en esa primera cuenta. La misma publicación explica que la verificación interna diseñada para impedir que se creara XRP también usaba un contador de 64 bits sin comprobación de overflow, por lo que podía desbordarse de forma idéntica. Eso significa que la barrera pensada para detectar emisión indebida no habría frenado ese escenario concreto. La falla, por tanto, no estaba en una cuenta comprometida ni en una transferencia mal firmada, sino en cómo el software conciliaba los montos dentro del pago.
Qué necesitaba un atacante para activarlo
Según XRP Ledger, el ataque no podía activarse por accidente. Requería cientos de cuentas y ofertas con precios artificialmente malos, seguidas por un pago construido específicamente para consumirlas todas a la vez. Esa condición técnica limitaba el alcance práctico del bug, pero no su gravedad, porque seguía abriendo la puerta a crear XRP que luego podía circular. No hacía falta robar claves ni tomar control de validadores: el punto débil estaba en el procesamiento del pago dentro del ledger.
Ese límite técnico también acota lo que no era este caso. No se trataba de un hackeo operacional clásico contra una wallet o un exchange, sino de un riesgo de integridad del ledger, es decir, de la consistencia de sus reglas internas. Los mantenedores añadieron en su informe que evaluaron el 24 de septiembre de 2026 un posible escenario de bloqueo de pagos en el libro de órdenes y lo descartaron como ataque práctico. La razón que dieron fue que esas ofertas quedarían al fondo del libro por tener precios antieconómicos.
Cómo se confirmó el impacto y cuándo salió el parche
El mismo día del reporte, XRP Ledger indica que RippleX Engineering reprodujo el ataque en un servidor standalone, una instancia aislada para pruebas, y en pruebas unitarias del código. Esa reproducción confirmó que el XRP creado podía gastarse en un pago posterior, no solo aparecer en un estado intermedio del sistema. Con ese resultado, la severidad del hallazgo pasó a crítica. El cambio de nivel importa porque muestra que el riesgo no era teórico una vez reconstruido el escenario.
La corrección llegó el 25 de septiembre de 2026 con xrpld 3.4.1. Los mantenedores informaron además que ese mismo día más del 80% de los validadores de la default UNL ya ejecutaban 3.4.1 o una versión posterior. Según su reporte, no encontraron evidencia de explotación en redes públicas antes de la divulgación. Ese dato reduce el daño conocido, pero no cambia que el bug hubiera permanecido durante años en una parte sensible del procesamiento de pagos.
Por qué la solución evitó el proceso normal de enmiendas
De acuerdo con XRP Ledger, la solución no siguió el proceso ordinario de enmienda del proyecto, que exige más de 80% de apoyo de validadores confiables durante dos semanas antes de activarse. Los mantenedores dijeron que fue la primera vez en más de diez años que un cambio de procesamiento de transacciones se envió deliberadamente de esa forma. La explicación que dieron fue operativa: publicar el cambio y esperar el ciclo completo habría expuesto con precisión el punto de ataque. En otras palabras, el procedimiento habitual habría dejado visible cómo explotar la falla antes de que la red estuviera suficientemente actualizada.
Esa excepción ayuda a distinguir entre divulgación pública y protección real. El informe se publicó el 9 de octubre, pero la mitigación dependía de que los servidores hubieran actualizado antes a xrpld 3.4.1 o a una versión posterior. Para quienes usan servicios que soportan XRP, el dato práctico no era solo que existiera un informe, sino si la infraestructura que procesa ese activo ya había aplicado la versión corregida. Ese es el punto que define si la red y sus servicios quedaron cubiertos frente a esta vulnerabilidad específica.
Qué se sabe del origen del bug y qué cifras siguen atribuidas
Según la investigación resumida por XRP Ledger, el bug probablemente estaba presente desde 2015, cuando se escribió el motor de pagos actual. El informe agrega que la verificación de "no XRP creado" se incorporó dos años después con la misma aritmética sin comprobación de overflow. Ese detalle importa porque muestra que la segunda barrera heredó la misma limitación que la primera, en vez de corregirla. También deja como antecedente que una falla de esta clase pudo pasar inadvertida durante casi una década.
Hay, además, datos que no salen cuantificados de esa forma en el informe oficial. The Block reportó que Cayden Liao, cofundador de Veria Labs, dijo que el exploit podía crear cerca de 18 billones de XRP en una sola transacción y que Ripple pagó a Veria Labs la recompensa máxima de 250.000 dólares del programa. Esas cifras están atribuidas a Liao en ese medio y no aparecen presentadas así en el informe abierto de XRP Ledger.
XRP en el mercado de Fluyez
XRP cotiza en 1.36 USD y baja 3.42 % en las últimas 24 horas, según los datos del propio mercado de Fluyez el 13 de octubre de 2026, 06:01 hora de Lima.
En soles, eso equivale a 4.68 PEN por unidad.
El dato verificado
- Precio: 1.36 USD
- Variación 24 horas: -3.42 %
- Equivalente: 4.68 PEN
- Datos del 13 de octubre de 2026, 06:01 hora de Lima
