Un error de 2015 en XRP Ledger permitía crear XRP de la nada: cómo funcionaba y por qué se corrigió sin votación

Durante unos diez años, el software que procesa los pagos de XRP Ledger tuvo un error que habría permitido crear XRP de la nada con una sola transacción. Cayden Liao y Veria AI lo reportaron el 22 de septiembre por el programa de recompensas por errores de la red, y los desarrolladores lo corrigieron en la versión 3.4.1 de xrpld, publicada el 25 de septiembre, sin pasar por la votación habitual de los validadores. “No hemos encontrado evidencia de que este problema se haya explotado en ninguna red pública”, dice el informe que los desarrolladores publicaron el 9 de octubre.

Te explicamos cómo funcionaba el error, por qué no lo detectaron los controles, por qué se corrigió sin votación y qué significa para quien tiene XRP.

Qué pasó, paso a paso

• 22 de septiembre: llega el reporte, calificado como “mayor”. RippleX, el brazo de desarrollo de Ripple, reproduce el ataque y lo sube a crítico.
• 22 y 23 de septiembre: la corrección se desarrolla y revisa en privado.
• 23 de septiembre: se incluye en la primera versión candidata de xrpld 3.4.1.
• 25 de septiembre: se publica xrpld 3.4.1. Ese mismo día, más del 80% de los validadores de la lista recomendada por defecto ya la usaban.
• 9 de octubre: se publica el informe con los detalles del error.

Cómo funcionaba el error

En XRP Ledger, un pago puede pasar por el libro de órdenes del exchange descentralizado integrado en la red y consumir varias ofertas para conseguir el mejor precio. Según el informe:

• Una suma que “daba la vuelta”. El motor de pagos sumaba los montos de esas ofertas con enteros de 64 bits, sin comprobar si el resultado superaba el máximo. Cuando lo superaba, el total volvía a empezar desde un número pequeño, como un cuentakilómetros que pasa de 999.999 a 000.000.
• XRP nuevo. Cada dueño de una oferta recibía su pago completo, pero al comprador se le cobraba solo ese total reducido. La diferencia era XRP recién creado, que se podía gastar, según RippleX.
• Cómo se armaba el ataque. Había que crear cientos de cuentas, cada una con una oferta que vendía una cantidad mínima de un token a cambio de una cantidad enorme de XRP, y luego enviar un pago que consumiera todas a la vez. Cada oferta, por separado, era válida.
• Un ataque barato. Costaba “unos pocos cientos de XRP” en reservas de cuentas y ofertas, que se recuperan al eliminarlas, más las comisiones normales. No hacía falta un saldo inicial grande.

La lectura de Criptoinforme: por qué ningún pago normal lo activaba. El código de xrpld guarda los montos de XRP en “drops” (1 XRP equivale a 1.000.000 de drops) como enteros de 64 bits con signo, cuyo máximo ronda los 9,2 trillones de drops, es decir, unos 9,2 billones de XRP. Para desbordarlo, las ofertas de un mismo pago tenían que sumar unas 92 veces los 100.000 millones de XRP que se crearon en el origen de la red. Por eso solo un ataque con ofertas artificiales podía llegar a ese umbral.

Por qué no lo detectaron los controles

• El control usaba la misma suma defectuosa. La regla que verifica que ninguna transacción cree XRP sumaba los cambios de saldo con la misma aritmética que se desbordaba, así que solo veía la comisión.
• El control por cuenta era demasiado amplio. Solo fallaba si una sola cuenta superaba el suministro total de XRP. Repartir el XRP creado entre cientos de cuentas lo evitaba.
• Diez años sin detectarse. El error probablemente existía desde que se reescribió el motor de pagos, en 2015. El control de XRP se añadió unos dos años después, con la misma aritmética.

Por qué se corrigió sin votación

Los cambios en las reglas de XRP Ledger suelen activarse mediante “enmiendas”: los validadores votan y la regla entra en vigor si mantiene más del 80% de apoyo durante dos semanas. Esta vez no se hizo así:

• Para no revelar el error. Publicar la corrección como enmienda habría dejado el error a la vista y explotable durante semanas, mientras se actualizaban los nodos y se votaba, según el informe.
• Entró en vigor al actualizar. La corrección se aplicó en cuanto cada operador instaló la versión 3.4.1, y el código se publicó después.
• Un riesgo asumido. Los desarrolladores reconocen que una red con versiones mezcladas podía quedar dividida, pero escribieron que “una detención de la red sería preferible a procesar transacciones de un ataque”.
• Una excepción, según sus autores. El informe la presenta como una medida única, reservada para los errores más graves. Es el primer cambio deliberado en el procesamiento de transacciones que se hace fuera del sistema de enmiendas, según el informe.

Lo que esto significa: la decisión protegió la red, pero también muestra que un grupo reducido, los desarrolladores de RippleX y la XRPL Foundation junto con los validadores de la lista por defecto, puede cambiar el comportamiento de la red en días. Estefano Gomez, autor de Crypto Briefing, escribió que la omisión del proceso de enmiendas “merece atención” porque deposita la confianza en el equipo central de desarrollo.

El segundo error: las transacciones en lote

El mismo informe describe un fallo en Batch (XLS-56), la función que permite agrupar varias transacciones en una sola:

• Qué fallaba. El servidor no verificaba el formato de las transacciones agrupadas. Una transacción armada a mano podía hacer que nodos con versiones distintas no se pusieran de acuerdo y detener la validación de la red.
• Sin impacto en fondos. La función todavía no estaba activa en la red principal, y el informe dice que no hubo pérdida de fondos.
• Cómo se resolvió. Ripple y el validador Vet retiraron su voto para reiniciar el plazo de activación. La corrección, fixBatchV1_2, y la función Batch se activaron en la red principal el 9 de octubre.

No es la primera vez que pasa algo así

El 15 de agosto de 2010, un desbordamiento parecido en Bitcoin permitió crear unos 184.000 millones de BTC en el bloque 74638. Se publicó una versión corregida del programa en menos de cinco horas, y al día siguiente la cadena válida superó a la defectuosa, según la wiki de Bitcoin. La diferencia es que en Bitcoin el error sí se explotó, mientras que en XRP Ledger se encontró antes, según el informe.

Qué significa para ti

• Si tienes XRP, no tienes que hacer nada. Según el informe, no hay evidencia de que el error se haya explotado.
• Si operas un nodo o un validador, debes usar xrpld 3.4.1 o una versión posterior para seguir sincronizado con la red.
• El precio no reaccionó. XRP cotizaba a US$1,40 el 10 de octubre a mediodía, hora de Bogotá, con una subida de 1,45% en 24 horas, según CoinGecko. Puedes seguirlo en nuestra página de precio de XRP.

Preguntas frecuentes

¿Se crearon XRP falsos?

No hay evidencia de eso. Los desarrolladores de XRP Ledger dicen que no encontraron indicios de que el error se haya explotado en ninguna red pública.

¿Mis XRP corren peligro?

No por este error, que ya está corregido en xrpld 3.4.1. El fallo no permitía robar saldos de otras cuentas: permitía crear XRP nuevo.

¿Por qué no votaron los validadores?

Porque publicar la corrección como enmienda habría revelado el error semanas antes de que se activara. La corrección entró en vigor cuando cada operador actualizó su software, y más del 80% de los validadores de la lista por defecto ya lo había hecho el día del lanzamiento.

Este artículo es informativo y no constituye asesoría de inversión.

Fuentes: XRP Ledger, “Vulnerability Disclosure Report for xrpld 3.4.1” (9 de octubre de 2026); xrpld, código fuente de XRPAmount (repositorio de rippled); Crypto Briefing (10 de octubre de 2026); DeFiprime (10 de octubre de 2026); Bitcoin Wiki, “Value overflow incident” (CVE-2010-5139); CoinGecko (precio de XRP, 10 de octubre de 2026).