Un fallo presente desde 2015 en el software que procesa los pagos de XRP Ledger permitía crear XRP sin respaldo mediante una sola transacción cuidadosamente preparada. El problema fue comunicado el 22 de septiembre por Cayden Liao y Veria AI a través del programa de recompensas de la red y quedó corregido tres días después, con el lanzamiento de xrpld 3.4.1.
El informe técnico publicado por los desarrolladores el 9 de octubre señala que no se ha encontrado evidencia de que la vulnerabilidad fuera explotada en una red pública. La actualización se desplegó sin recurrir al sistema habitual de enmiendas y votación de los validadores, una decisión excepcional para evitar que el fallo quedara expuesto antes de que la mayoría de los nodos pudiera actualizarse.
Una suma que podía reiniciarse desde cero
El error estaba en el motor de pagos de XRP Ledger, que también permite ejecutar operaciones a través del exchange descentralizado integrado en la red. Cuando una orden necesita consumir varias ofertas, el software suma los importes correspondientes para obtener el mejor precio disponible.
Esas cantidades se manejaban como enteros de 64 bits, pero el programa no comprobaba si el resultado superaba el máximo permitido. Al rebasarlo, la cifra volvía a comenzar desde un valor pequeño, de forma parecida a un cuentakilómetros que pasa de su límite y regresa a cero.
El efecto podía ser relevante: los propietarios de las ofertas recibían el pago completo, mientras que al comprador se le cargaba únicamente la suma reducida después del desbordamiento. La diferencia podía convertirse en XRP nuevo y quedar disponible para ser gastada, según la explicación de RippleX.
Para activar el fallo no bastaba con enviar un pago normal. El atacante debía crear cientos de cuentas y colocar en cada una una oferta que vendiera una cantidad mínima de un token a cambio de una cantidad desproporcionadamente grande de XRP. Después tendría que construir un pago capaz de consumir todas esas ofertas en una sola operación.
El coste inicial era limitado: unos pocos cientos de XRP en reservas para las cuentas y las ofertas, además de las comisiones habituales. Las reservas podían recuperarse al eliminar esos objetos. El umbral necesario, sin embargo, era extraordinario. El informe explica que las ofertas debían sumar aproximadamente 92 veces los 100.000 millones de XRP creados en el origen de la red para provocar el desbordamiento.
Por qué los controles no detectaron la creación de XRP
La red contaba con una comprobación destinada a impedir que una transacción generase XRP. El problema es que ese control utilizaba la misma aritmética defectuosa que provocaba el desbordamiento. En lugar de identificar la cantidad creada, podía interpretar que el único cambio neto era la comisión de la operación.
Además, la verificación por cuenta estaba diseñada para detectar que una sola dirección superase el suministro total de XRP. Al distribuir el resultado entre cientos de cuentas, el ataque podía esquivar ese límite. Según el informe, el fallo probablemente se introdujo cuando se reescribió el motor de pagos en 2015; el control del suministro se añadió unos dos años más tarde y heredó el mismo problema de cálculo.
Una corrección fuera del proceso habitual
En circunstancias normales, los cambios en las reglas de XRP Ledger se activan mediante enmiendas. Los validadores deben mantener más de un 80% de apoyo durante dos semanas para que una modificación entre en vigor. En este caso, publicar una enmienda habría revelado la vulnerabilidad y dejado una ventana de varias semanas antes de su activación.
RippleX reprodujo el ataque el mismo 22 de septiembre y elevó la clasificación del reporte de “mayor” a “crítico”. La corrección se desarrolló y revisó en privado los días 22 y 23, se incorporó a una versión candidata y se publicó el 25 de septiembre. Ese día, más del 80% de los validadores de la lista recomendada por defecto ya utilizaba la nueva versión.
Los desarrolladores reconocieron que mantener nodos con versiones distintas podía provocar una división de la red, pero consideraron preferible una eventual detención a procesar transacciones de un ataque. El informe describe la decisión como una excepción reservada para fallos de máxima gravedad.
El mismo documento recoge otro problema relacionado con la función Batch (XLS-56), que permite agrupar transacciones. Una operación construida manualmente podía hacer que nodos con versiones diferentes discreparan y detuvieran la validación. La función aún no estaba activa en la red principal, no hubo pérdida de fondos y el problema se resolvió antes de su activación, junto con la corrección fixBatchV1_2, el 9 de octubre.
Para los titulares de XRP, el informe no exige ninguna acción: no hay indicios de explotación ni de robo de saldos. Los operadores de nodos y validadores sí deben utilizar xrpld 3.4.1 o una versión posterior para seguir sincronizados con la red.
