Los desarrolladores de XRP Ledger han corregido un fallo crítico del motor de pagos que podría haber permitido a un atacante crear XRP gastables muy por encima del límite de suministro de 100.000 millones de la red en una sola transacción, según un informe de divulgación de Veria Labs. La vulnerabilidad existía en el código de xrpld desde 2015, aunque el informe señaló que «no había pruebas de que este problema se hubiera explotado en ninguna red pública».
El fallo se notificó a RippleX el 22 de septiembre y se corrigió tres días después en la versión 3.4.1 de xrpld. Veria Labs afirmó que más del 80 % de los validadores de la Unique Node List predeterminada de XRP Ledger habían instalado la versión el día de su lanzamiento, lo que limitó la ventana práctica para un ataque contra la red.
Cayden Liao, cofundador de Veria Labs, afirmó que un agente de IA identificó el fallo y generó un exploit funcional. En una publicación en X, Liao estimó que una sola transacción maliciosa podría haber creado aproximadamente 18 billones de XRP —unas 184 veces el suministro máximo original de la red— si hubiera llegado a una red vulnerable.
El cálculo de pagos podía desbordarse
La vulnerabilidad afectaba a los pagos que consumen múltiples ofertas del libro de órdenes descentralizado de XRP Ledger. Estas transacciones pueden ejecutarse contra muchas ofertas a la vez, por lo que el software debe sumar la cantidad de XRP pagada en todas ellas.
Según el informe de Veria Labs, esa suma no contaba con una comprobación de desbordamiento. En informática, se produce un desbordamiento cuando un número es demasiado grande para el tipo de datos asignado; en lugar de producir el valor grande correcto, el cálculo puede volver a un número mucho menor.
Un atacante podría haber utilizado varios cientos de cuentas para colocar ofertas de venta de una fracción minúscula de un token a cambio de cantidades extraordinariamente grandes de XRP. Después, una sola transacción de pago podría haber consumido esas ofertas. El motor de pagos abonaría a cada vendedor la cantidad de XRP indicada, mientras que el coste calculado para el comprador podría volver a «solo unos cientos de drops más la comisión», según el informe. Un drop es la unidad más pequeña de XRP, equivalente a una millonésima parte de un XRP.
El error podría haber aumentado los saldos de XRP sin adeudar correctamente la cuenta del atacante. Veria Labs afirmó que otra medida de protección, diseñada para detectar XRP recién creados, utilizaba otra operación de suma vulnerable al desbordamiento. Como resultado, la comprobación interna del suministro del protocolo también podría no haber detectado el aumento artificial de los saldos.
La magnitud del exploit teórico lo situaba en una categoría diferente a la de un compromiso típico de un exchange o del robo de fondos de un puente. En lugar de robar fondos existentes de un fondo definido, el atacante podría haber introducido nuevas unidades gastables en circulación, socavando potencialmente la confianza en las reglas de suministro del libro mayor si esas unidades llegaban a plataformas de trading u otros participantes de la red.
La solución eludió el calendario normal de enmiendas
El parche de RippleX entró en vigor mediante actualizaciones de los servidores, en lugar del proceso habitual de enmiendas de XRP Ledger, según Veria Labs. Por lo general, las enmiendas modifican las reglas de la red solo después de recibir más del 80 % de apoyo de validadores de confianza durante dos semanas.
Este proceso está diseñado para dar a los operadores tiempo para revisar y desplegar las actualizaciones antes de que una regla del protocolo se active. En este caso, el problema de seguridad requería una respuesta más rápida: cada servidor recibió la protección cuando su operador actualizó a xrpld 3.4.1.
Veria Labs describió este enfoque como el primer uso de esta vía de activación basada en actualizaciones en más de una década de enmiendas de XRP Ledger. La decisión refleja el equilibrio práctico al gestionar una vulnerabilidad con un plazo de corrección corto: un debate público amplio antes de que un parche se despliegue de forma generalizada puede proporcionar a los atacantes suficientes detalles técnicos para reconstruir el exploit.
Justin Bons, fundador y director de inversiones de Cyber Capital, escribió en X que xrpld 3.4.1 había permanecido como código cerrado durante unas dos semanas antes de que se publicara el código. Mayukha Vadari, ingeniera de software de RippleX, dijo que las preocupaciones sobre el descubrimiento rápido y la ingeniería inversa determinaron el proceso de publicación.
Esa secuencia llamó la atención porque las redes de código abierto generalmente dependen de la revisión pública del código, mientras que una restricción temporal del acceso al código fuente limita el examen independiente. El enfoque de RippleX dio prioridad a prevenir la explotación mientras los operadores de validadores desplegaban la corrección, y después publicó el código una vez transcurrido el periodo urgente.
Un segundo parche solucionó un problema de la función Batch
La versión 3.4.1 también solucionó un problema independiente relacionado con Batch, una función que aún no se había activado cuando los investigadores identificaron el primer fallo. Veria Labs dijo que la vulnerabilidad de Batch podría haber detenido la red en determinadas circunstancias.
El informe señaló que un atacante no obtendría activos en la cadena mediante el problema de Batch. Su posible impacto consistía en crear un registro del libro mayor permanentemente malformado que podría interrumpir servicios externos a la cadena, como indexadores, exploradores de blockchain y kits de desarrollo de software. Estos servicios interpretan y organizan los datos del libro mayor para monederos, aplicaciones y usuarios; por lo tanto, los registros malformados pueden generar problemas operativos incluso cuando los saldos del libro mayor permanecen intactos.
Veria Labs indicó que Batch y su corrección se activaron el viernes, y que los servidores que ejecutan versiones antiguas del software ya no pueden permanecer sincronizados con la red. Esto crea un fuerte incentivo para que los operadores restantes actualicen sus sistemas, ya que los servidores obsoletos no pueden seguir de forma fiable el estado actual del libro mayor.
Liao afirmó que Veria Labs recibió la recompensa máxima de 250.000 $ por informar sobre las vulnerabilidades. La recompensa refleja la posible gravedad de un fallo que afectó a la lógica contable central de una blockchain pública, en lugar de a una aplicación periférica.
El incidente también aporta pruebas de que el análisis automatizado de código se está convirtiendo en una parte práctica del descubrimiento de vulnerabilidades. El relato de Liao sobre un agente de IA que encontró y explotó el problema no demuestra que la automatización pueda sustituir la revisión de seguridad humana, pero muestra con qué rapidez pueden detectarse antiguos errores aritméticos cuando los investigadores combinan el análisis automatizado con el conocimiento técnico de las reglas de transacción de un protocolo.
La reparación de XRP Ledger evitó que la vulnerabilidad se convirtiera en un evento de oferta visible para el mercado. Las preguntas restantes se centran en si otras bases de código maduras de blockchain contienen riesgos similares de desbordamiento de enteros en rutas de transacción complejas, especialmente cuando se agregan varias operaciones y los saldos se comprueban mediante rutinas contables independientes.
¿Te preocupan los riesgos del protocolo tras este fallo de XRP Ledger? Explora la dinámica de los pagos entre cadenas en este análisis de pagos transfronterizos.
Aviso legal: El contenido de esta página se proporciona únicamente con fines informativos generales y no representa las opiniones ni el asesoramiento financiero de Toobit. No garantizamos la exactitud o integridad de esta información y no asumimos responsabilidad por ningún error, omisión o consecuencia derivada de su uso. Invertir en activos digitales implica riesgos; los usuarios deben evaluar de forma independiente su situación financiera y los riesgos involucrados. Para obtener más información, consulta nuestros Términos del servicio y Declaración de riesgos.
