Resumen
Una vulnerabilidad crítica del XRP Ledger que había permanecido en el motor de pagos durante aproximadamente una década podría haber permitido teóricamente a un atacante crear XRP gastable más allá de las reglas de suministro previstas del ledger. XRPL divulgó el problema el 9 de octubre de 2026, después de que se informara de forma privada a través del Programa de Recompensas por Errores de XRPL el 22 de septiembre. La vulnerabilidad afectaba a xrpld 3.4.0 y versiones anteriores y se corrigió en xrpld 3.4.1, publicado el 25 de septiembre.
La vulnerabilidad del XRP Ledger implicaba un desbordamiento de enteros cuando un pago consumía cientos de ofertas del libro de órdenes construidas especialmente. Los propietarios individuales de las ofertas podían recibir sus cantidades completas de XRP mientras que al comprador solo se le cobraba un pequeño total con desbordamiento. Más grave aún, la invariante existente del ledger de “no se crea XRP” utilizaba una ruta aritmética similar y podía desbordarse de la misma manera, impidiendo que esa verificación de seguridad detectara la discrepancia.
XRPL afirma que no encontró evidencia de que la vulnerabilidad fuera explotada en ninguna red pública, y que los pagos normales no podían desencadenarla accidentalmente. El ataque requería ofertas deliberadamente diseñadas con precios económicamente irreales. Aun así, el incidente plantea una pregunta de seguridad más profunda: la política monetaria fija de una blockchain es tan sólida como el software que hace cumplir cada transición de saldo.
Puntos Clave
- El error parece haber existido desde que se escribió el motor de pagos actual de XRPL en 2015.
- Una transacción construida deliberadamente podría haber creado teóricamente XRP gastable.
- XRPL no encontró evidencia de explotación en una red pública.
- La invariante de suministro existente podría fallar porque reproducía el mismo comportamiento de desbordamiento.
xrpld 3.4.1añadió aritmética verificada y una verificación de suministro independiente más fuerte.
¿Qué era la vulnerabilidad del XRP Ledger?
La vulnerabilidad residía en el manejo de la liquidez del libro de órdenes por parte del motor de pagos del XRP Ledger. Cuando un pago se mueve a través de múltiples ofertas, el motor tiene que calcular cuánto XRP debe el pagador en total. Cada cantidad individual podía ser válida, pero el cálculo agregado utilizaba un entero de 64 bits sin suficiente protección contra desbordamiento.
En condiciones normales, esto era efectivamente inalcanzable. El suministro normal de XRP y los precios reales del mercado no se acercan remotamente al límite numérico requerido para desbordar el contador. El problema surgió solo cuando un atacante construyó deliberadamente cientos de ofertas en las que cada cuenta solicitaba una cantidad extremadamente grande de XRP por una cantidad minúscula de otro token.
Un flujo malicioso podría verse aproximadamente así:
- Crear varios cientos de cuentas controladas.
- Colocar ofertas deliberadamente irreales desde esas cuentas.
- Construir un pago diseñado para consumir esas ofertas juntas.
- Llevar el cálculo agregado de XRP más allá del límite del entero.
- Hacer que el total se desborde a un número mucho menor.
El motor podría entonces acreditar a los propietarios de las ofertas individualmente mientras cobraba al comprador solo el total desbordado. Como el atacante también podía controlar las cuentas de los propietarios de las ofertas, la diferencia se convertía efectivamente en nuevo XRP.
Los ingenieros de XRPL reprodujeron el ataque localmente y confirmaron que el XRP resultante podía transferirse posteriormente. En consecuencia, el problema se elevó de Mayor a severidad crítica.
¿Podría realmente la vulnerabilidad del XRP Ledger crear XRP?
Sí, teóricamente. Esto no era meramente un error de visualización contable. La divulgación técnica de XRPL dice que el exploit podría haber creado XRP que se comportaba como XRP ordinario después de que se validara la transacción maliciosa. Esos saldos podrían haberse movido, intercambiado o enviado a exchanges.
Eso no significa que históricamente se haya emitido XRP en exceso. XRPL informa que no encontró ninguna evidencia de que el exploit ocurriera en ninguna red pública. La diferencia entre esas dos afirmaciones es esencial: la vulnerabilidad podría violar la restricción de suministro prevista, pero actualmente no hay ningún evento histórico de suministro confirmado asociado con ella.
El ataque tampoco podría ocurrir accidentalmente durante el comercio normal en el DEX. Las ofertas del libro de órdenes tenían que tener precios tan irreales que la liquidez normal del mercado se ejecutaría antes de alcanzarlas. Además, un pago tenía que construirse intencionalmente para consumir suficientes de esas ofertas juntas para desencadenar el desbordamiento.
Por lo tanto, esto se entiende mejor como una ruta de ejecución de baja probabilidad con un impacto teórico extremadamente alto, en lugar de un error que los usuarios ordinarios de XRP podrían haber desencadenado sin saberlo.
¿Por qué falló la verificación de seguridad del suministro de XRPL?
La parte técnicamente más importante del incidente no es simplemente que existiera un desbordamiento de enteros. El software financiero maduro a menudo contiene múltiples capas defensivas diseñadas para detectar exactamente ese tipo de resultado inesperado.
XRPL tenía una: una invariante de transacción destinada a garantizar que una transacción no pudiera crear XRP. En principio, incluso si el motor de pagos cometía un error contable, la invariante debería haber notado que los saldos totales de XRP aumentaban y haber rechazado la transacción.
No lo hizo.
La razón es un fallo clásico de sistemas de seguridad supuestamente independientes. El invariante calculaba los cambios netos de XRP utilizando un tipo similar de aritmética no verificada. Cuando el motor de pagos se desbordó, el cálculo del invariante pudo desbordarse en la misma dirección, haciendo que la transacción resultante pareciera haber cambiado el suministro de XRP solo por la comisión de transacción ordinaria.
Una verificación de seguridad no es verdaderamente independiente cuando puede reproducir el mismo modo de fallo que el sistema que está verificando.
Una segunda protección verificaba si el saldo de una cuenta individual excedía el suministro total de XRP. Eso tampoco detuvo el ataque porque el XRP recién creado podía distribuirse entre cientos de cuentas, manteniendo cada saldo individual por debajo del límite.
Por lo tanto, la remediación abordó tanto el error inmediato como la arquitectura defensiva. xrpld 3.4.1 añadió verificaciones explícitas de desbordamiento cuando los montos se agregan a través de ofertas y rutas de pago. XRPL también cambió el invariante de no-XRP-creado para usar un contador más amplio que no puede desbordarse en las mismas condiciones.
¿Por qué un error de 2015 permaneció oculto durante tanto tiempo?
La respuesta radica en parte en la diferencia entre los valores económicos realistas y los límites teóricos de la computación. Los pagos individuales de XRP operan muchos órdenes de magnitud por debajo del rango requerido para desbordar una suma de 64 bits. Un comerciante normal podría usar XRPL durante años sin crear nada parecido a las condiciones numéricas maliciosas.
Esto hizo que el fallo fuera difícil de exponer mediante el uso rutinario. La lógica vulnerable podía comportarse correctamente a lo largo de miles de millones de operaciones normales y aún así fallar catastróficamente en un límite artificial.
La vulnerabilidad también demuestra por qué el código blockchain de larga vida no debe considerarse automáticamente seguro simplemente porque ha operado durante muchos años. El historial de producción es evidencia útil, pero principalmente prueba estados comunes. Los atacantes buscan deliberadamente estados que los usuarios normales nunca crean.
XRPL atribuyó a su Programa de Recompensas por Errores el hallazgo del problema y ha esbozado un enfoque más amplio de defensa en profundidad que incluye auditorías independientes, attackathons públicos, fuzzing, red teaming asistido por IA y verificación formal. También está añadiendo la reverificación de las correcciones de seguridad contra los candidatos de lanzamiento antes de que los hallazgos se cierren formalmente.
Ese enfoque importa porque la lección de este incidente no es que el código maduro no sea confiable. Es que el código maduro aún requiere pruebas adversarias contra suposiciones que los desarrolladores dejaron de cuestionar años atrás.
¿Qué significa el error para el suministro fijo de XRP?
XRP comenzó con un suministro inicial definido de 100 mil millones de tokens, sin un mecanismo de protocolo análogo a la minería de prueba de trabajo que cree continuamente XRP adicional. Las comisiones de transacción se destruyen en lugar de pagarse a los validadores, por lo que la trayectoria de suministro prevista es no inflacionaria.
La vulnerabilidad del XRP Ledger expone una distinción importante entre la política monetaria como regla y la política monetaria como aplicación de software.
Una especificación de blockchain puede declarar que no se puede crear nuevo XRP, pero los nodos finalmente aplican esa propiedad a través del código. Si la lógica de transición de saldos puede manipularse para violar la regla, entonces la política económica misma puede fallar aunque la política documentada no haya cambiado.
Este incidente no demostró que el suministro circulante real de XRP se incrementara en secreto. XRPL dice que no se encontró explotación en la red pública. Pero sí demostró que, antes del parche, existía una ruta de ejecución teórica capaz de eludir una de las restricciones monetarias más fundamentales del ledger.
Eso hace que esta vulnerabilidad sea más trascendental que una interrupción temporal de RPC o un problema de conectividad de nodos. Una red puede tolerar ciertas interrupciones de infraestructura sin comprometer la integridad de los activos. Un error capaz de generar unidades gastables toca la base contable del propio ledger.
Por qué la corrección importa más que la ausencia de un exploit
Es tentador descartar una vulnerabilidad una vez que los investigadores dicen que nunca fue explotada. Eso perdería la lección de seguridad más útil.
La línea de tiempo de respuesta de XRPL fue relativamente comprimida: el problema se reportó y reprodujo el 22 de septiembre, la corrección se desarrolló y revisó entre el 22 y el 23 de septiembre, se fusionó en la rama de lanzamiento 3.4.1 y se lanzó el 25 de septiembre. XRPL informó que más del 80% de los validadores predeterminados de la Lista de Nodos Únicos estaban ejecutando la versión protegida el mismo día.
La corrección del motor de pagos también surtió efecto directamente con la actualización de software en lugar de esperar el proceso normal de activación de enmiendas. Eso fue posible porque rechazar el desbordamiento aritmético se trató como una corrección de comportamiento indefinido o inseguro en lugar de introducir una nueva regla de transacción prevista.
Para la seguridad de la blockchain, el momento de la divulgación es parte de la defensa. Publicar el exploit antes de que los validadores estuvieran protegidos habría convertido una vulnerabilidad teórica en instrucciones operativas para los atacantes. Por lo tanto, XRPL divulgó los detalles técnicos después de que la versión parcheada ya se hubiera propagado.
Riesgos y limitaciones
El incidente es grave, pero varios límites deben permanecer claros.
- Ningún evento de inflación confirmado: XRPL afirma que no encontró evidencia de explotación en una red pública.
- Ningún desencadenante accidental: los pagos normales y los libros de órdenes realistas no alcanzan los valores necesarios.
- La adopción del parche importa: se espera que los operadores de servidores ejecuten
xrpld 3.4.1o una versión más reciente. - Una corrección no prueba la seguridad completa: otras suposiciones aritméticas antiguas aún merecen pruebas adversarias.
- La ausencia histórica de abuso no puede reemplazar la verificación formal: algunas clases de errores son demasiado inusuales para surgir a través de la actividad normal de la red.
Otra limitación es la certeza retrospectiva. Los investigadores pueden analizar el historial del ledger y los patrones de exploit conocidos, pero probar que una vulnerabilidad nunca fue utilizada es inherentemente diferente de probar matemáticamente que no podría haber sido utilizada. Por lo tanto, la conclusión oficial se enmarca apropiadamente como no se encontró evidencia, en lugar de una afirmación absoluta sobre cada estado histórico.
Perspectiva de MEXC: la oferta fija es una propiedad de seguridad del software
La política monetaria de una blockchain no está protegida por un número de oferta escrito únicamente en la documentación. Está protegida por el software que valida cada cambio de saldo, ruta de transacción y estado del ledger.
El incidente de XRPL ilustra por qué esta distinción importa. La regla prevista del protocolo prohibía crear nuevos XRP, sin embargo, un fallo en la aritmética podría teóricamente haber violado esa regla. Más importante aún, la invariante defensiva diseñada para detectar la creación de oferta inicialmente compartía el mismo modo de fallo.
Para las redes blockchain maduras, la seguridad por lo tanto necesita ir más allá de probar si las transacciones normales se comportan correctamente. Las invariantes independientes, el fuzzing, las pruebas de límites adversarias y los métodos formales se vuelven cada vez más importantes precisamente porque las vulnerabilidades más dañinas pueden existir en rutas de código que los usuarios comunes nunca tocan.
La métrica que vale la pena observar después de esta divulgación no es la reacción del precio de XRP. Es si los procesos de verificación ampliados de XRPL encuentran y aíslan consistentemente clases similares de riesgo latente del protocolo antes que los atacantes.
El error de hace una década era crítico, no un evento probado de inflación de XRP
La vulnerabilidad del XRP Ledger merece la descripción de “crítica” porque teóricamente podría haber socavado una de las garantías más fundamentales de XRPL. Un pago cuidadosamente diseñado podría forzar un desbordamiento aritmético de 64 bits, acreditar a cientos de propietarios de ofertas con XRP y cobrar al comprador solo una fracción del monto agregado. Los saldos recién creados eran gastables en la propia reproducción del ataque por parte de XRPL.
Pero la segunda mitad de la historia es igualmente importante. XRPL no encontró evidencia de explotación en la red pública, la transacción requería condiciones deliberadamente anormales del libro de órdenes, y la vulnerabilidad fue parcheada en xrpld 3.4.1 antes de que los detalles técnicos se divulgaran públicamente.
Por lo tanto, el incidente no debe reescribirse como evidencia de que la oferta de XRP fue históricamente inflada. Su significado es más estructural. Muestra que incluso una blockchain de oferta fija depende en última instancia de que el software haga cumplir correctamente las restricciones monetarias en casos límite que pueden permanecer invisibles durante años.
La conclusión más fuerte de esta vulnerabilidad del XRP Ledger es, en consecuencia, sobre ingeniería de protocolos más que sobre titulares de oferta de tokens. Las invariantes monetarias necesitan una implementación independiente, el código antiguo aún requiere revisión adversaria, y la operación exitosa de la red durante una década no elimina la posibilidad de fallos ocultos en condiciones límite. El error no probó que se hubieran emitido XRP en exceso; probó por qué la integridad de la oferta debe verificarse continuamente.
Fuentes
Divulgación oficial de vulnerabilidad de XRPL:
https://xrpl.org/es-es/blog/2026/vulnerabilitydisclosurereport-bug-20261009
Información de la versión XRPL 3.4.1:
https://xrpl.org/blog
¿Quieres obtener las últimas noticias de MEXC lo más rápido posible? ¡Únete ahora a nuestro grupo oficial de Telegram!
Plataforma MEXC: Descargar App | Trading sin comisiones | Comprar USDT ahora Únete a la comunidad MEXC: X (Twitter) | Telegram | Discord
Obtener información: Academia para principiantes | Términos de servicio | MEXC Blog | MEXC News
Verificación de cuenta: Conocer KYC | Cómo realizar KYC
Advertencia de riesgo: El contenido de este artículo es solo para referencia y no constituye ningún consejo de inversión. El mercado de monedas digitales es altamente volátil, tome decisiones prudentes según su propia situación.
