Ripple usa IA para cazar vulnerabilidades en XRP Ledger y promete más mejoras

Ripple detalló los primeros resultados de su red team asistido por IA para XRP Ledger: cientos de issues divulgados, 20 hallazgos corregidos en rippled 3.1.3 y una hoja de ruta que promete más endurecimiento antes de futuras enmiendas.

***

• El equipo reportó 287 issues públicos de xrpld en GitHub, además de hallazgos en xrpl-py, xrpl.js y xrpl-rust.
• Ripple afirma que los problemas divulgados son mejoras de calidad y defensa en profundidad, sin impacto en estabilidad, disponibilidad o fondos.
• La versión 3.1.3 de rippled se dedicó a seguridad y corrección de bugs, con 20 hallazgos del red team asistido por IA.

Ripple ofreció una mirada poco habitual al trabajo interno de seguridad que realiza sobre XRP Ledger, la red blockchain que opera de forma continua desde 2012 y que, según el equipo, ya procesó más de 3.000 millones de transacciones. La compañía explicó que su red team asistido por inteligencia artificial lleva dos meses buscando vulnerabilidades de manera continua en el código de XRPL.

El esfuerzo no apunta solo a encontrar errores aislados. Ripple busca revisar un código base que acumuló más de una década de evolución, decisiones de ingeniería antiguas, nuevas funciones y múltiples capas de interacción entre subsistemas. Ese contexto vuelve difícil que una sola persona pueda entender todos los riesgos posibles.

De acuerdo con el informe técnico publicado por RippleX, la versión 3.1.3 de rippled fue el primer lanzamiento dedicado por completo a seguridad y corrección de bugs surgido de esta iniciativa. No incorporó nuevas funciones. Su foco estuvo en endurecimiento, correcciones y preparación para un despliegue seguro en mainnet.

La ingeniera de software de Ripple Mayukha Vadari resumió el avance al señalar que el equipo lleva dos meses con este esfuerzo de red team de IA y que el objetivo era mostrar qué herramientas usan, qué bugs corrigieron y qué aprendieron. En una respuesta posterior, aclaró que los problemas divulgados son principalmente mejoras de calidad de código y defensa en profundidad, y que ninguno afecta la estabilidad del sistema, la disponibilidad ni la seguridad de los fondos.

Un red team asistido por IA para una red con más de una década

XRPL tiene una particularidad relevante para los lectores nuevos: no es una cadena experimental recién lanzada. Ripple destaca que su funcionamiento continuo desde 2012 representa un historial importante, pero también implica una carga técnica significativa. El software creció junto con nuevas necesidades, funciones y patrones de uso.

Ese crecimiento incluye el servidor principal rippled, el servidor de API Clio y varios SDK de cliente. Entre ellos están xrpl.js, xrpl-py, xrpl4j, xrpl-rust y xrpl-go. Cada capa añade posibles puntos de fricción entre lógica de negocio, validación de datos, memoria, transacciones y servicios externos.

Ripple sostiene que los modelos de IA permiten revisar código con más profundidad y amplitud que una auditoría manual tradicional. La ventaja no consiste solo en leer más archivos. También permite explorar casos límite donde distintas funciones correctas por separado pueden generar comportamientos inesperados cuando interactúan.

El pipeline combina agentes personalizados de búsqueda de bugs, escaneos de DepthFirst, pruebas de inyección de fallos con Antithesis, reportes de investigadores externos y bots de revisión de pull requests. GitHub Copilot y un bot basado en Claude, gestionado por Ripple, comentan directamente en los PR de rippled para detectar problemas antes de que lleguen al código base principal.

DepthFirst aporta una capa de análisis para rastrear flujos de datos, lógica de negocio e interacciones entre servicios. Ripple indicó que usa su modelo de bajo nivel para C/C++, ajustado para encontrar problemas de seguridad de memoria y confusión de tipos. Antithesis, en cambio, ejecuta rippled bajo condiciones adversarias para revelar fallos que dependen de concurrencia, carga, fallos parciales u ordenamientos inusuales de transacciones.

De la detección al parche: cómo funciona el ciclo de seguridad

El equipo no presenta el descubrimiento como una etapa suficiente. Ripple explicó que el valor real del proceso aparece cuando los hallazgos pasan por deduplicación, triaje, revisión humana, enrutamiento y corrección. Esta estructura busca evitar que la IA genere ruido sin impacto operativo.

El ciclo comienza con hallazgos candidatos provenientes de pipelines de IA, DepthFirst, Antithesis e investigadores externos. Luego el equipo cruza esos reportes con tableros existentes para evitar tickets duplicados. Después llega una fase automatizada de triaje que intenta identificar causa raíz, falsos positivos, pruebas de reproducción y severidad.

Para medir severidad, Ripple indicó que usa la OWASP Risk Rating Methodology. Aun así, la compañía subrayó que la revisión humana sigue siendo esencial. Los expertos del dominio validan los resultados, sobre todo en bugs sutiles de invariantes donde un modelo puede malinterpretar la semántica prevista.

Los bugs confirmados se envían al equipo de ingeniería correcto con reportes completos y pruebas de reproducción adjuntas. Las correcciones llegan mediante el sistema de enmiendas cuando afectan elementos on-ledger, o mediante parches directos cuando se trata de problemas off-ledger. La cobertura incluye motor de transacciones, capa RPC, protocolo peer/overlay, AMM, MPT, Vault, Lending, Permission Delegation y NFT.

Hasta ahora, el equipo divulgó públicamente 287 issues de xrpld en GitHub. De ellos, 231 siguen abiertos y 49 aparecen cerrados, mientras el triaje continúa y se crean más incidencias. También se divulgaron 44 issues en xrpl-py, 48 en xrpl.js y 126 en xrpl-rust, con varios problemas ya parcheados en SDK.

La versión 3.1.3 corrigió hallazgos críticos y altos

La versión 3.1.3 de rippled incluyó 20 hallazgos del red team en distintas categorías. El caso más sensible fue un crash crítico vinculado a Permissioned Domain y Tickets. Una combinación específica de una transacción basada en Ticket con la función PermissionedDomain podía activar una colisión de keylet y bloquear el validador.

Ese bug lo detectó inicialmente el equipo de XRPL Commons en marzo. Una primera corrección, incluida en 3.1.2, arregló el crash, pero no la causa raíz porque eso requería una enmienda. Durante las pruebas de lanzamiento para 3.1.3, Antithesis encontró un segundo problema de crash con la misma causa raíz, lo que llevó a una corrección completa asociada al PR #7129.

Otro hallazgo relevante fue un crash de alta severidad en Ledger RPC API v2. El endpoint tenía una ruta de crash accesible desde cualquier conexión pública, sin autenticación. Una solicitud malformada podía tumbar el nodo. Ripple lo presentó como un caso fácil de pasar por alto en revisión manual, pero visible mediante generación sistemática de entradas adversarias.

El lanzamiento también incluyó una lectura de heap fuera de límites en HTTP Forwarded Header, una denegación de servicio por validación de tamaño de nodo hoja SHAMap, un problema de parsing JSON de STArray sin comprobación de límites y un crash de deserialización de STIssue mediante issuer noAccount(). También corrigió acceso fuera de límites a un array por char con signo en strUnHex.

En MPT y pagos, el equipo corrigió un caso donde removeEmptyHolding y authorizeMPToken podían eliminar un MPToken con escrow activo, además de una lectura obsoleta en rippleSendMultiMPT que permitía exceder MaximumAmount. En Vault se abordaron un bypass del límite de trustline mediante retiro denominado en shares y una falla de Clawback All con importe cero cuando el Vault tenía préstamos pendientes.

En Lending, las correcciones incluyeron llamadas associateAsset omitidas para operaciones LoanManage con flags, una comprobación invariante ValidLoanBroker CoverAvailable invertida y una estimación de tarifa sin límite en LoanPay::calculateBaseFee que sobrecobraba a usuarios. También se corrigió que transacciones dry-run pudieran encolarse en la TxQ real durante una escalada de tarifas.

Otros hallazgos de menor severidad incluyeron removeExpired ignorando de forma silenciosa un fallo de deleteSLE, un mensaje de error idéntico para condiciones opuestas en la invariante ValidLoan y una falta de comprobación de array AdditionalBooks vacío en ValidPermissionedDEX para ofertas híbridas. U.Today también señaló que 3.1.3 incluyó mejoras a la enmienda fixCleanup3_1_3, una colección de correcciones para NFT, Permissioned Domains, Vaults y Lending Protocol.

Ripple promete más mejoras y posible apertura del pipeline

El director de ingeniería de RippleX Vijay Khanna destacó que Vadari fue la principal cazadora durante la iniciativa. También agradeció a los operadores de la UNL por actualizar a la nueva versión en tiempo récord. Según su mensaje, se dedicó una enorme cantidad de esfuerzo a garantizar que este lanzamiento pudiera desplegarse de forma segura en mainnet.

Khanna planteó que la actualización 3.1.3 es solo el comienzo. El equipo espera que lanzamientos futuros, incluido 3.2.0, incorporen más correcciones del backlog de hallazgos confirmados. La meta es elevar el listón de seguridad antes de que nuevas enmiendas lleguen a mainnet.

Ripple también planea ampliar el análisis sobre interacciones entre funciones. Esa zona aparece como una de las más difíciles, porque muchos bugs importantes no nacen dentro de un módulo aislado. Surgen cuando dos o más funciones, correctas individualmente, se combinan de formas poco obvias.

El equipo seguirá ejecutando pruebas de inyección de fallos de Antithesis en nuevas ramas de lanzamiento. Además, prepara attackathons más completos sobre nuevas enmiendas antes de su activación. Esta estrategia sugiere una aproximación más preventiva, no solo reactiva, para futuras funciones del protocolo.

Vadari también explicó por qué el equipo contempla abrir sus pipelines cuando corrija todos los bugs explotables. A su juicio, nadie puede impedir que terceros desarrollen sus propios pipelines y busquen vulnerabilidades. Además, existe una cantidad finita de bugs, en especial los explotables, dentro de una base de código.

La posible apertura tendría varias aplicaciones. Serviría para aumentar transparencia, permitir que desarrolladores ejecuten el pipeline sobre funciones o PR grandes, y facilitar que otros miembros de la comunidad mejoren la herramienta. La seguridad, según el enfoque descrito, depende tanto de IA como de revisión humana y coordinación responsable con el ecosistema.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público

Este artículo fue escrito por un redactor de contenido de IA

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín