Una falla en XRP Ledger detectada por IA expuso una vía para acuñar 18,45 billones de XRP
Veria AI detectó una falla en XRP Ledger que, según los investigadores, podría acuñar 18,45 billones de XRP, pese al suministro fijo de 100.000 millones de la criptomoneda.
El exploit combinaba una aritmética defectuosa en el motor de pagos del ledger con una comprobación de seguridad que repetía el mismo error. Un pago especialmente construido podía acreditar a cientos de cuentas vendedoras mientras cobraba al comprador una cantidad casi nula.
RippleX reprodujo el exploit, lo clasificó como crítico y lanzó xrpld 3.4.1 el 25 de septiembre de 2026. La divulgación oficial indica que los investigadores no encontraron pruebas de que alguien hubiera explotado la vulnerabilidad en una red pública.
La distinción importa. No fue un robo de 18 billones de XRP, ni la cantidad teórica tenía un valor de mercado realizable. Era una vía creíble para vulnerar la regla de suministro que define a XRP.
El incidente también pone a prueba una promesa más amplia en torno a la seguridad asistida por IA. Al parecer, un agente de IA encontró un defecto de una década de antigüedad que las auditorías y las pruebas convencionales no habían detectado. Aun así, investigadores humanos tuvieron que validar el resultado, coordinar una corrección confidencial y convencer a los validadores de actualizarse.
La falla de XRP Ledger se corrigió antes de su divulgación pública
La historia inmediata es una respuesta de emergencia exitosa ante una vulnerabilidad que había permanecido accesible durante casi una década.
Veria Labs afirma que dirigió su agente de seguridad a rippled, el software de servidor de código abierto utilizado por XRP Ledger. La empresa dice que su sistema identificó el código vulnerable, desarrolló un exploit funcional y lo probó en una red local.
La reconstrucción técnica de la firma sitúa el hallazgo inicial de la IA el 21 de septiembre. Según Veria, el sistema produjo una prueba de concepto funcional al día siguiente.
El investigador Cayden Liao revisó el resultado y lo reportó a través del programa de recompensas por errores de XRPL el 22 de septiembre. Los ingenieros de RippleX confirmaron el problema ese mismo día tras reproducirlo en un servidor independiente y dentro de su marco de pruebas.
La confirmación fue más allá de demostrar una discrepancia contable. RippleX estableció que el XRP recién creado podía transferirse en un pago posterior, lo que hacía que el resultado fuera operativamente utilizable.
Los desarrolladores integraron una corrección el 23 de septiembre y lanzaron rippled 3.4.1 dos días después. La divulgación pública esperó hasta el 9 de octubre, después de que los operadores dispusieran de tiempo para instalar el software corregido.
Veria afirma que más del 80 por ciento de los validadores ejecutaban la versión el 25 de septiembre. La cuenta oficial de XRPL informa de forma similar que más del 80 por ciento de los validadores de la Unique Node List predeterminada se actualizaron ese día.
Una Unique Node List, o UNL, identifica a los validadores en los que confía un servidor al evaluar el consenso. La rápida adopción entre esos validadores redujo el peligro creado por nodos antiguos que siguieran aceptando la transacción vulnerable.
La respuesta se apartó de la vía habitual para modificar el comportamiento de las transacciones. Por lo general, XRPL introduce cambios sensibles al consenso mediante enmiendas, que los validadores consideran antes de su activación.
Los desarrolladores incorporaron directamente la corrección del desbordamiento en la versión del servidor. Retuvieron temporalmente los cambios de código fuente pertinentes, limitando la posibilidad de que atacantes aplicaran ingeniería inversa a la vulnerabilidad antes de que suficientes validadores se actualizaran.
Esa decisión concentró la confianza en los mantenedores y operadores de validadores durante un breve periodo. También evitó que un proceso público de enmienda se convirtiera en un manual para un error de inflación inmediatamente explotable.
El informe oficial señala que la XRPL Foundation, RippleX y los validadores participantes consideraron que la actualización confidencial era más segura que dejar disponible un exploit abierto durante semanas. La corrección se hizo pública después de que la red superara el umbral de seguridad necesario.
Veria recibió la recompensa crítica máxima de 250.000 dólares el 8 de octubre. La cantidad reconoce la clasificación de gravedad, pero no debe confundirse con una pérdida cuantificada.
No se detectó XRP no autorizado, no se informó de fondos de usuarios desaparecidos y ninguna transacción del ledger público se ha vinculado al exploit. La emergencia concernía a lo que aceptaba el código, no a daños ya observados.
Ese resultado hace fácil minimizar el evento. Sin embargo, evitar la explotación no reduce la importancia de un defecto que podría invalidar la premisa de suministro fijo del activo.
Cómo la falla de XRP Ledger podía crear XRP utilizable
El exploit funcionaba porque dos salvaguardas monetarias realizaban cálculos vulnerables de manera casi idéntica.
El primer defecto aparecía en el manejo por parte del motor de pagos de las ofertas del exchange descentralizado integrado de XRP Ledger. Las ofertas permiten a las cuentas intercambiar XRP o activos emitidos mediante los libros de órdenes del ledger.
Un atacante comenzaría creando muchas cuentas controladas y emitiendo un token sin valor. Esas cuentas colocarían luego cientos de ofertas artificiales que exigieran cantidades extremadamente grandes de XRP a cambio de ese token.
La prueba de concepto de Veria utilizó 256 ofertas. Cada una solicitaba algo más de 2^56 drops, donde un drop representa una millonésima parte de un XRP.
El atacante enviaría entonces un pago diseñado para consumir toda la colección de ofertas. El motor de pagos tenía que sumar las cantidades de XRP asociadas a cada oferta antes de cobrar al comprador.
Ese total superaba la capacidad del entero sin signo de 64 bits utilizado para el cálculo. Un desbordamiento de enteros ocurre cuando un valor supera su máximo permitido y vuelve a un número mucho menor.
En este caso, el agregado superaba 2^64 drops. Los propietarios de las ofertas individuales podían recibir sus cantidades completas, mientras que el desbordamiento hacía que el cargo combinado al comprador pareciera ser de solo 256 drops.
Esto era más grave que una cotización de intercambio incorrecta. Los saldos acreditados representaban XRP que ninguna cuenta de origen había suministrado.
El resultado fue de aproximadamente 18.446.744.073.709 XRP, antes de contabilizar el débito de origen y la comisión de transacción. Veria resume el resultado utilizable como unos 18,45 billones de XRP repartidos entre 256 cuentas.
Esa distribución era esencial. XRPL aplica un límite al XRP que puede mantener una sola cuenta, pero cada destinatario se mantenía por debajo de ese límite.
Por tanto, el ataque eludía una salvaguarda al dividir el nuevo XRP entre muchas cuentas. Los investigadores afirman que el XRP acreditado podía luego moverse mediante pagos ordinarios o llegar a exchanges.
XRPL también tenía un invariante destinado a evitar precisamente este resultado. Un invariante es una condición de seguridad posterior a la transacción que debe seguir siendo verdadera antes de que el ledger acepte un cambio.
El invariante XRPNotCreated calculaba el cambio neto del saldo de XRP en toda la transacción. Debería haber rechazado cualquier resultado que mostrara que la transacción creó más XRP del que destruyó mediante comisiones.
Sin embargo, ese cálculo utilizaba una aritmética vulnerable al mismo desbordamiento. El cambio neto se desbordaba hasta parecer una quema ordinaria de comisiones, permitiendo que la transacción fuera aceptada.
En efecto, el motor de pagos calculaba mal lo que debía el comprador. La comprobación de suministro, aparentemente independiente, repetía entonces el fallo matemático y aprobaba el resultado falso.
Este fallo compartido es la lección crítica de diseño. Un control de respaldo ofrece una protección limitada cuando depende del mismo tipo de datos, comportamiento aritmético o supuesto que el componente al que supervisa.
El ataque no era algo que un operador ordinario pudiera activar por accidente. Requería cientos de ofertas con precios deliberadamente establecidos y un pago diseñado para consumirlas en conjunto.
También requería algo de XRP para las reservas de cuentas y ofertas, además de las comisiones de transacción. El informe de vulnerabilidad estima el requisito en unos pocos cientos de XRP, y la mayoría de las reservas podía recuperarse posteriormente.
El atacante no necesitaba controlar un validador. Una vez preparada y firmada, la transacción del exploit entraría en la red como un pago por lo demás ordinario.
El ataque también era repetible. Grupos adicionales de cuentas controladas podían recrear la configuración, permitiendo otro lote de 18,45 billones de XRP.
La corrección introdujo comprobaciones de desbordamiento en el código que suma las ofertas. Un total que supera el rango permitido ahora falla en lugar de desbordarse y convertirse en un cargo pequeño.
Los desarrolladores también ampliaron el acumulador utilizado por el invariante de suministro. Otras rutas de suma de saldos recibieron un refuerzo relacionado para reducir la posibilidad de otro fallo aritmético compartido.
Un suministro fijo hacía que el daño potencial fuera sistémico
La exposición real no era el valor nominal imposible de 18,45 billones de XRP, sino la credibilidad de cada unidad legítima que ya circulaba.
XRP comenzó con un suministro total de 100.000 millones de tokens. No se produce mediante minería ni staking, y las comisiones ordinarias de transacción destruyen pequeñas cantidades con el tiempo.
Ese diseño ofrece a los usuarios una expectativa monetaria sencilla. Las transacciones pueden redistribuir XRP, pero nunca deberían aumentar el suministro total.
La falla de XRP Ledger violaba esa regla en la capa contable. Si se hubiera explotado, podría haber colocado XRP recién creado en cuentas normales sin marcar visiblemente esos saldos como diferentes.
El resultado reportado de 18,45 billones equivalía a unas 184 veces el suministro original. Sin embargo, multiplicar esa cantidad por el precio de mercado produce una medida engañosa del daño económico.
Un atacante no podría vender billones de XRP al precio previo al ataque. La liquidez disponible desaparecería, los exchanges podrían suspender la negociación y el precio reaccionaría mucho antes de que la mayoría de los tokens llegara a un comprador.
La referencia más significativa era la capitalización de mercado aproximada de 94.000 millones de dólares de XRP cuando Veria evaluó la vulnerabilidad. Representaba el valor cuya premisa subyacente de escasez se enfrentaba a presión.
Incluso esta cifra no es una estimación de pérdidas garantizada. La capitalización de mercado no equivale al efectivo almacenado dentro de una red, y distintos tenedores experimentarían resultados diferentes.
El riesgo sistémico procedía de la confianza. Una emisión no autorizada podría diluir a los tenedores existentes, saturar la liquidez de los exchanges, interrumpir aplicaciones y plantear dudas sobre las garantías contables del ledger.
Las instituciones también se enfrentarían a incertidumbre operativa. Los exchanges podrían necesitar identificar depósitos afectados, los proveedores de pagos podrían pausar la liquidación y los custodios podrían restringir los retiros durante una investigación.
Esas respuestas podrían perjudicar a usuarios legítimos incluso si un atacante capturara solo una pequeña parte de la cantidad destacada en los titulares. Un fallo de suministro se extiende más allá de las cuentas directamente implicadas.
Esto ayuda a explicar la versión confidencial. Los mantenedores protegían tanto el protocolo como el margen de respuesta disponible para exchanges, validadores y proveedores de infraestructura.
Es probable que la falla hubiera existido desde que se escribió el motor de pagos en 2015. Según el análisis de Veria, una segunda debilidad en el invariante de suministro databa de 2017.
Esa cronología pone en entredicho la idea de que la longevidad por sí sola demuestra seguridad. El software puede procesar miles de millones de transacciones y conservar una vía de explotación que la actividad normal nunca activa.
Ripple afirmó en marzo que XRPL había procesado más de 100 millones de ledgers y tres mil millones de transacciones desde 2012. Esas cifras demuestran un uso extensivo, pero no cubren todos los estados aritméticos posibles.
Aquí importaba la entrada poco común. Los pagos normales no podían acercarse al valor necesario para el desbordamiento porque el suministro legítimo de XRP estaba muy por debajo de ese umbral.
Un atacante tuvo que fabricar valores extremos del libro de órdenes en muchas ofertas. Es posible que las pruebas convencionales basadas en comportamientos económicos plausibles nunca hayan explorado esa combinación.
Las auditorías tampoco eliminaron el riesgo. Veria afirma que la base de código fue sometida a más de una docena de auditorías o concursos de auditoría desde 2024, además de contar con un programa de recompensas ya establecido.
Esto no demuestra que las auditorías fueran negligentes. Las auditorías operan con restricciones de tiempo, alcance e incentivos, mientras que interacciones poco comunes pueden permanecer ocultas entre componentes separados.
La lección es más acotada y útil. El código financiero maduro necesita pruebas que desafíen los límites de las máquinas, no solo escenarios que se asemejen al comportamiento habitual de los usuarios.
La seguridad con IA encontró el fallo, pero los humanos lo contuvieron
El descubrimiento respalda la seguridad asistida por IA, mientras que la respuesta demuestra por qué el escaneo autónomo es solo una capa de la defensa de un protocolo.
Veria atribuye tanto el descubrimiento como la construcción del exploit a su agente de seguridad con IA. La compañía afirma que el sistema analizó rippled, conectó las dos debilidades aritméticas y creó una prueba de concepto local funcional.
Ese relato es significativo porque la vulnerabilidad exigía razonamiento entre componentes. Encontrar únicamente el desbordamiento en los pagos no garantizaría el éxito si el invariante de suministro rechazaba la transacción.
Según se informa, el agente reconoció que el invariante repetía el desbordamiento. Luego diseñó una entrada que activaba ambos fallos dentro de una sola transacción.
Las afirmaciones de Veria cuentan con un respaldo externo importante. RippleX reprodujo el exploit de forma independiente, confirmó que el XRP acuñado podía gastarse y elevó el informe de grave a crítico.
La divulgación oficial de XRPL no ofrece una evaluación completa de la autonomía del agente. Confirma el informe y el resultado técnico, pero no mide de forma independiente cuánto de la dirección humana produjo el descubrimiento.
Esa brecha importa al evaluar productos de seguridad con IA. Un hallazgo exitoso puede involucrar análisis automatizado de código, prompts redactados por humanos, revisión iterativa y validación manual de exploits en proporciones distintas.
Aun así, el incidente aporta más evidencia que una puntuación de referencia. Dio lugar a una vulnerabilidad crítica confirmada, una versión de producción y el pago de la recompensa máxima.
Ripple ya había anunciado un programa más amplio de seguridad con IA en marzo de 2026. Ese programa combinaba pruebas asistidas por IA con un equipo rojo dedicado, fuzzing, verificación formal y una revisión más estricta de las enmiendas.
Las pruebas de fuzzing introducen en el software entradas inesperadas o malformadas para exponer fallos y estados inválidos. La verificación formal emplea técnicas matemáticas para comprobar si el software cumple propiedades definidas.
Estos métodos abordan modos de fallo diferentes. La IA puede inspeccionar código y proponer rutas de ataque, los fuzzers pueden explorar espacios de entrada y los métodos formales pueden comprobar invariantes críticos.
Los ingenieros humanos siguen decidiendo si un hallazgo es alcanzable, si su impacto es real y cómo repararlo sin alterar el consenso. También gestionan la divulgación entre una base descentralizada de operadores.
La respuesta de XRP Ledger ilustra claramente esta división. El agente encontró la ruta, Liao la revisó y RippleX reprodujo el exploit en entornos controlados.
Después, los desarrolladores modificaron varias rutas aritméticas. Los operadores de validadores instalaron la versión, mientras los mantenedores supervisaban la adopción antes de revelar los detalles.
Ningún participante controló todo el resultado. El sistema dependía de la cooperación entre una empresa privada de seguridad, desarrolladores de código abierto, una fundación, RippleX y operadores independientes.
Esa coordinación es una fortaleza porque varias partes examinaron el hallazgo. También es una dependencia de gobernanza que merece escrutinio.
El parche de emergencia se distribuyó antes de que la explicación a nivel de código se hiciera pública. Los validadores tuvieron que decidir si confiaban en la versión sin contar con la transparencia habitual disponible para los cambios rutinarios.
La alternativa conllevaba su propio peligro. Publicar la mecánica exacta del desbordamiento antes de una adopción amplia habría dado a los atacantes una ruta funcional contra todos los validadores sin parchear.
Esta es la disyuntiva central, no una simple competencia entre la IA y la auditoría humana. Un descubrimiento más rápido incrementa el valor de procedimientos de respuesta rápidos, confiables y cuidadosamente gobernados.
Las mismas herramientas que ayudan a los defensores a inspeccionar código antiguo también pueden ayudar a los atacantes a buscar errores equivalentes. La ingeniera de RippleX Mayukha Vadari advirtió en la divulgación que la IA modifica los plazos en torno al descubrimiento y la explotación de vulnerabilidades.
Por tanto, un programa maduro necesita más que mejores escáneres. Necesita divulgación confidencial ensayada, estándares claros de severidad, canales de comunicación con validadores y una preparación para actualizaciones que pueda medirse.
Lo que el fallo de XRP Ledger no demuestra
El exploit confirmado fue grave, pero varias interpretaciones de los titulares van más allá de la evidencia disponible.
Primero, no hay evidencia de que 18,45 billones de XRP hayan entrado en un libro mayor público. Los investigadores crearon la salida en un entorno controlado mientras validaban la vulnerabilidad.
Segundo, ninguna fuente ha establecido que los atacantes conocieran la ruta antes de que Veria la informara. La antigüedad del código vulnerable describe el tiempo de exposición, no un conocimiento adversario confirmado.
Tercero, los supuestos $94.000 millones en riesgo no deben tratarse como una previsión de pérdidas. Describen el mercado cuya garantía de escasez enfrentaba un daño potencial.
Cuarto, el incidente no establece que un sistema de IA completara de forma independiente cada etapa de la investigación. Veria proporcionó el relato más detallado sobre el papel del agente, mientras que los humanos realizaron la revisión y la divulgación.
Estas salvedades no convierten el hallazgo en algo teórico en un sentido despectivo. RippleX reprodujo la transacción y confirmó que un pago posterior podía gastar el nuevo XRP.
La vulnerabilidad también llegó al código de producción. No se trató de una función propuesta detectada antes de su activación, a diferencia de un problema separado de transacciones Batch reparado en la misma versión 3.4.1.
Combinar ambos incidentes puede generar confusión. El fallo de Batch se refería a la validación de wrappers y a un posible desacuerdo entre versiones de servidores.
Esa enmienda Batch no se había activado en la red principal. Los validadores gestionaron su reparación mediante votación de enmiendas, y la versión corregida se activó el 9 de octubre.
El desbordamiento de XRP siguió una ruta diferente. Afectaba al comportamiento existente del motor de pagos y se reparó de inmediato cuando los nodos instalaron la versión 3.4.1.
Por tanto, el registro de la versión contiene dos correcciones de seguridad con historiales de exposición y gobernanza distintos. Solo el desbordamiento de pagos creó la presunta ruta de acuñación.
Otra incertidumbre se refiere a la detección histórica. XRPL afirma no haber encontrado evidencia de explotación en redes públicas, pero los lectores deben distinguir entre “sin evidencia” y una prueba absoluta de ausencia.
Un atacante que utilizara el exploit crearía cambios de saldo y actividad en el libro de órdenes inusuales. Esos rastros deberían facilitar el análisis retrospectivo, especialmente dada la necesidad de cientos de ofertas artificiales.
Sin embargo, la divulgación pública no presenta una metodología forense completa ni una búsqueda del historial del libro mayor auditada de forma independiente. Su conclusión sigue siendo el hallazgo reportado por los mantenedores.
La rápida actualización de la red también merece un examen continuo. Una adopción superior al 80 por ciento entre los validadores default-UNL redujo la exposición inmediata, pero otros nodos y proveedores de infraestructura siguen calendarios diferentes.
El software antiguo no puede hacerse seguro mediante una declaración de divulgación. Los operadores que ejecutan rippled 3.4.0 o versiones anteriores siguen siendo responsables de actualizarse.
Por último, este evento no demuestra que la IA haya completado la auditoría de blockchain. Demuestra que un proceso asistido por IA encontró un error importante en una base de código madura.
La siguiente prueba es la repetibilidad. Los equipos de seguridad necesitan evidencia de que sistemas similares detectan vulnerabilidades diversas y previamente desconocidas sin inundar a los mantenedores con informes débiles.
También deben evaluar el uso adversario. Un descubrimiento defensivo más rápido solo es valioso cuando la reparación y el despliegue pueden superar a la reproducción maliciosa.
Tres señales mostrarán si el modelo de seguridad mejoró
La próxima fase debe juzgarse a través del código, el comportamiento de los validadores y resultados de seguridad reproducibles de forma independiente.
La primera señal es la adopción continuada de rippled 3.4.1 o posterior. La corrección crítica del desbordamiento se aplica durante la instalación del software, por lo que los nodos desactualizados siguen siendo el riesgo evitable más claro.
La telemetría pública de los validadores debería mostrar que las versiones vulnerables desaparecen de los roles de consenso relevantes. Una adopción lenta debilitaría la afirmación de que XRPL puede coordinarse en condiciones urgentes.
La segunda señal es una revisión técnica de los invariantes monetarios más allá de este parche específico. La comprobación de suministro fallida compartía un comportamiento aritmético con el componente que debía supervisar.
Los desarrolladores deberían probar otros totales, conversiones y rutas de saldo con acumuladores más amplios y un manejo explícito de desbordamientos. Una revisión independiente reforzaría más la confianza que otra garantía general.
La tercera señal es evidencia de que las pruebas asistidas por IA producen hallazgos repetibles bajo divulgación responsable. Vulnerabilidades confirmadas, bajas tasas de falsos positivos y una supervisión humana clara respaldarían la afirmación más amplia de Veria.
Una sucesión de informes sensacionalistas pero no verificados la debilitaría. Lo mismo ocurriría con hallazgos que requieran una extensa reconstrucción humana no divulgada antes de volverse accionables.
El incidente ya modifica la base de referencia de seguridad. Una larga operación, auditorías previas y un diseño de suministro decreciente no evitaron que un error de límite de máquina amenazara la regla monetaria central de XRP.
Al mismo tiempo, la respuesta funcionó antes de que apareciera un exploit público. Los investigadores informaron el problema, los ingenieros lo reprodujeron y los validadores instalaron una reparación de emergencia en cuestión de días.
Los desarrolladores y operadores de infraestructura deberían preguntarse ahora si sus propias comprobaciones de seguridad fallan de forma distinta a los sistemas que supervisan. Una suposición duplicada no constituye una verdadera defensa en profundidad.
Para los lectores que siguen el fallo de XRP Ledger, la acción más útil es observar la adopción de versiones, la revisión independiente del código y las futuras divulgaciones de recompensas. Esas señales revelarán si se trató de una reparación aislada o del inicio de un modelo de seguridad más sólido.
