Estos días, el ecosistema de activos digitales ha estado congestionado por la cantidad de noticias relacionadas con ciberataques, pérdidas millonarias, ataques a la cadena de suministro de fabricantes de hardwallets, etc., y ahora llega la más reciente, el parche a la red XRP Ledger que pudo haber costado miles de millones de dólares.
Para entender lo que está pasando con XRP, hay que comenzar diciendo que una vulnerabilidad de desbordamiento de enteros (integer overflow), que permaneció latente en el núcleo del motor de pagos de XRP Ledger (XRPL) durante casi una década ha ocasionado una rápida respuesta de la Fundación XRP Ledger y de RippleX.
Esta vulnerabilidad, de haber sido explotada, habría permitido a un atacante generar tokens XRP disponibles para el gasto desde la nada, burlando el límite estricto de 100.000 millones de unidades que constituye la base del modelo económico de la red, es decir su tokenomía.
La revelación, detallada en el informe oficial de divulgación de seguridad de la versión xrpld 3.4.1, no solo expuso las complejidades técnicas de mantener un código heredado desde 2015, sino que también desencadenó una respuesta operativa sin precedentes, porque por primera vez en más de diez años, los desarrolladores y validadores optaron por aplicar una corrección de código directa omitiendo el proceso formal de votación y enmienda que caracteriza la gobernanza descentralizada de la red.
The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let’s clear them up.
1. Was any XRP created?
No. XRP’s supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around…
— XRP Ledger Foundation (@XRPLF) October 11, 2026
En el comunicado publicado en su cuenta oficial de Fundación XRP Ledger en la red social X, se señala: “Una corrección pública muestra a los atacantes dónde está el error, y la IA lo hace rápido. Con una votación de enmienda normal, la corrección habría sido pública durante semanas antes de entrar en vigor, arriesgando la seguridad de la red”.
El origen del problema se remontaba al desarrollo del motor de pagos actual en 2015, que permite que en el libro de órdenes integrado de XRPL, las cuentas de los usuarios puedan publicar ofertas para intercambiar activos. La vulnerabilidad residía en la forma en que el sistema calculaba el costo total cuando un solo pago consumía cientos de ofertas simultáneas.
Para ejecutar el ataque, un actor malicioso no requería un capital millonario ni accesos privilegiados, con tan solo efectuar un procedimiento que consistía en abrir varios cientos de cuentas bajo su control, publicando ofertas para vender una cantidad minúscula de un token secundario a cambio de una suma desproporcionadamente alta de XRP, ya con eso cada oferta, tomada de forma aislada, era perfectamente válida dentro de las reglas del libro mayor.
Sin embargo, cuando una cuenta compradora ejecutaba un único pago diseñado para liquidar todas esas ofertas a la vez, el software sumaba los importes adeudados utilizando una variable de entero de 64 bits sin verificación de límite.
Al superar el valor máximo almacenable por la variable, el contador interno sufría un desbordamiento y se reiniciaba a un número extremadamente bajo, un fenómeno análogo al de un cuentakilómetros analógico que pasa de 999.999 a 000.000.
El resultado era devastador para la contabilidad de la red porque el motor acreditaba el pago completo de XRP a cada una de las cuentas vendedoras, mientras que a la cuenta compradora solo se le debitaba el total redondeado a cero o a unos pocos drops (la unidad mínima de XRP).
La diferencia entre lo pagado y lo acreditado se traducía en XRP recién creados que nunca debieron existir y para empeorar la situación, el sistema de auditoría interna de XRPL —la comprobación invariante diseñada para verificar que ninguna transacción genere tokens de la nada— utilizaba el mismo tipo de contador de 64 bits defectuoso.
Dado que la suma global sufría el mismo reinicio aritmético, la verificación determinaba que el cambio neto reflejaba únicamente la comisión de red habitual, permitiendo que la transacción se validara sin levantar ninguna alerta.
No obstante, este no era el único fallo a pesar de ser una de las redes blockchain más usadas en el mercado porque el informe de seguridad reveló que la versión 3.4.1 también abordó una segunda vulnerabilidad crítica vinculada a la propuesta XLS-56 (transacciones Batch), que permite empaquetar hasta ocho operaciones individuales en una sola ejecución atómica.
Identificada inicialmente durante las revisiones del Sherlock Attackathon y posteriormente analizada por Denis Angell (de XRPL Foundation) y Mayukha Vadari (de RippleX), la falla permitía que las transacciones internas de un lote fueran encapsuladas en campos de objetos no canónicos en lugar de la etiqueta obligatoria RawTransaction.
Si bien esta modificación no se encontraba activa en la red principal (Mainnet) y no ocasionó pérdida de fondos, representaba dos riesgos graves, ya que por un lado, amenazaba la estabilidad del consenso por las diferencias en la definición de campos entre distintas versiones del servidor (xrpld 3.3.0 frente a 3.4.0) las cuales habrían llevado a que unos nodos aceptaran transacciones que otros descartaban, paralizando la validación de nuevos bloques.
Pero también por otro lado, la presencia de contenedores no canónicos habría dañado de forma permanente la lectura de datos por parte de los indexadores, exploradores de bloques y SDKs oficiales (xrpl.js, xrpl-py), obligando a aplicar parches continuos en el ecosistema fuera de la cadena.
Frente a la notificación realizada el 22 de septiembre de 2026 por el investigador Cayden Liao y la firma Veria AI a través del programa XRPL Bug Bounty, los equipos de ingeniería de RippleX, la XRPL Foundation y los mantenedores principales debieron enfrentar un dilema estratégico.
Y es que, en condiciones normales, cualquier modificación en la lógica de procesamiento de transacciones de XRPL requiere una propuesta de enmienda (Amendment), puesto que este proceso exige que más del 80% de los validadores de confianza de la lista UNL (Unique Node List) voten a favor del cambio de forma continua durante un período de dos semanas.
Sin embargo, publicar una corrección de código abierto en un repositorio público para iniciar el proceso de votación habría expuesto la vulnerabilidad exacta ante la comunidad global y por consiguiente habría generado problemas.
Sobre todo, en un contexto donde el uso de herramientas de inteligencia artificial (IA) acelera la ingeniería inversa de exploits, mantener el código expuesto pero inactivo durante semanas habría dejado a la red principal vulnerable a ataques masivos.
Por esta razón, la comunidad de desarrollo tomó la decisión inédita de eludir el proceso de enmienda para el fallo del motor de pagos, lanzando el pasado 25 de septiembre de 2026 la versión xrpld 3.4.1, para que los operadores de validadores de la UNL coordinaran la actualización directa de sus nodos.
Fue de esta forma que en menos de 24 horas, más del 80% de la red ejecutaba la versión corregida, cerrando la brecha antes de que el código fuera analizado públicamente. Por su parte, la vulnerabilidad ligada a las transacciones por lote sí siguió el protocolo estandarizado mediante la activación de la enmienda fixBatchV1_2, la cual entró en vigor formalmente el 9 de octubre de 2026 tras completar su ciclo de votación.
A pesar de la gravedad del hallazgo, las auditorías forenses posteriores confirmaron que el error nunca fue explotado en ninguna red pública desde 2015 hasta su resolución en 2026, ya que la composición del ataque —requería cientos de ofertas con precios ilógicos ejecutadas en una ruta de código muy específica— evitó que el problema fuera desencadenado por el tráfico ordinario del mercado.
El suministro de XRP se mantiene en su cifra histórica verificable de aproximadamente 99.986 millones de tokens, cuyo carácter deflacionario continúa garantizado por la quema constante de comisiones de red.
Este incidente ha marcado un punto de inflexión en la estrategia de auditoría del ecosistema cripto y como respuesta, la XRP Ledger Foundation y RippleX anunciaron el fortalecimiento de sus programas de defensa en profundidad, incorporando pruebas adversariales asistidas por inteligencia artificial y la implementación rigurosa de Verificación Formal (Formal Verification).
Este último, es un método matemático que permite demostrar la corrección absoluta del código antes de que cualquier línea sea desplegada en la red