XRPL Corrige un error crítico en la actualización por lotes que podría haber drenado fondos, descubierto por una herramienta de seguridad AI
La Fundación XRP Ledger confirmó el 26 de febrero de 2026 que se identificó y parcheó una vulnerabilidad crítica en la lógica de validación de firmas de la enmienda por lotes propuesta, antes de su activación, evitando un posible exploit que podría haber permitido a los atacantes ejecutar transacciones no autorizadas y drenar fondos sin acceso a las claves privadas de las víctimas.
Descubierta por el ingeniero de seguridad Pranamya Keshkamat y la herramienta de seguridad autónoma de IA de Cantina, Apex, el 19 de febrero, la falla fue abordada mediante una versión de emergencia de rippled 3.1.1 el 23 de febrero, sin riesgo de fondos ya que la enmienda permanecía en fase de votación y nunca se activó en la red principal.
Cronología del Descubrimiento y Divulgación
El 19 de febrero de 2026, se identificó una falla lógica crítica en el código de validación de firmas de la enmienda por lotes para XRP Ledger. La vulnerabilidad fue descubierta mediante análisis estático del código de rippled por Pranamya Keshkamat, ingeniero de seguridad en la firma de ciberseguridad Cantina, en colaboración con la herramienta de IA autónoma Apex de Cantina.
El equipo de descubrimiento envió rápidamente un informe responsable de divulgación a la Fundación XRPL, permitiendo que los equipos de ingeniería de Ripple validaran el hallazgo con una prueba de concepto independiente y reproducción completa de pruebas unitarias. Los esfuerzos de remediación comenzaron esa misma noche.
Hari Mulackal, CEO de Cantina y Spearbit, afirmó que “nuestro cazador de errores autónomo, Apex, encontró este error crítico”, añadiendo que “si se hubiera explotado, habría sido el mayor hackeo de seguridad por valor en dólares en el mundo, con casi 80 mil millones de dólares en riesgo directo”, haciendo referencia a la capitalización de mercado de XRP.
Naturaleza Técnica de la Vulnerabilidad
La vulnerabilidad residía en la lógica de validación de firmas de la enmienda por lotes, una función propuesta que permitiría la ejecución atómica de hasta ocho transacciones en una sola operación por lotes. Cuando se habilitaba, las transacciones internas en un lote se firmaban intencionadamente sin firma, con la autorización delegada completamente a la lista de firmantes del lote externo.
La causa raíz fue un error crítico en un bucle en la función responsable de validar a esos firmantes. Cuando el validador encontraba un firmante cuya cuenta aún no existía en el libro mayor y cuya clave de firma coincidía con su propia cuenta —el caso normal para una cuenta nueva—, declaraba éxito inmediatamente y salía, omitiendo la validación de todos los demás firmantes.
Este fallo creaba una ruta clara de explotación: un atacante podía construir una transacción por lotes que contuviera tres transacciones internas—una creando una cuenta controlada por él, otra simple desde esa nueva cuenta (que la hacía un firmante requerido), y otra de pago desde una cuenta víctima al atacante. Al proporcionar dos entradas de firmantes por lotes—una legítima para la nueva cuenta y otra falsificada que afirmaba autorizar la cuenta víctima pero firmada con la clave del atacante—la validación saldría con éxito tras la primera entrada y nunca validaría la segunda, permitiendo que el pago de la víctima se ejecutara sin que sus claves participaran nunca.
Impacto Potencial y Remediación
Si la enmienda por lotes se hubiera activado antes de detectar la falla, un atacante podría haber robado fondos ejecutando transacciones de pago internas que drenaran las cuentas víctimas hasta el saldo de reserva, modificado el estado del libro mayor mediante transacciones no autorizadas de AccountSet, TrustSet o AccountDelete, y potencialmente desestabilizado todo el ecosistema por la pérdida de confianza en XRPL.
Tras confirmar la vulnerabilidad, se contactó inmediatamente a los validadores UNL y se les aconsejó votar en contra de la enmienda por lotes. La versión de emergencia rippled 3.1.1 se publicó el 23 de febrero de 2026, marcando tanto Batch como fixBatchInnerSigs como no soportados, impidiendo que recibieran votos de validadores o que se activaran en la red.
Se ha implementado una enmienda de reemplazo corregida, BatchV1_1, con la lógica completa arreglada, eliminando la condición de salida temprana, añadiendo salvaguardas adicionales de autorización y reforzando la verificación de firmas. Actualmente, esta versión está en revisión exhaustiva antes de su lanzamiento, sin un plazo establecido.
Rol Emergente de la IA en Ciberseguridad
El descubrimiento resalta el papel creciente de la inteligencia artificial en aplicaciones de ciberseguridad. Apex, la herramienta autónoma de IA de Cantina, identificó la vulnerabilidad mediante análisis estático del código, demostrando la capacidad de la IA para detectar errores sutiles que podrían pasar desapercibidos por revisores humanos.
Este incidente coincide con avances en la industria en seguridad impulsada por IA. El 20 de febrero, Anthropic lanzó Claude Code Security, un escáner de vulnerabilidades de ciberseguridad basado en IA que la compañía afirma “puede razonar como un investigador de seguridad experto”. La aparición de estas herramientas señala un posible cambio en cómo se identifican y abordan las vulnerabilidades en infraestructuras críticas.
Respuesta de la Fundación XRPL y Medidas Futuras
La Fundación XRPL ha delineado una hoja de ruta para mejoras de seguridad en respuesta al incidente, incluyendo la incorporación de pipelines de auditoría de código asistidos por IA como paso estándar en el proceso de revisión, ampliando la cobertura de análisis estático para detectar retornos de éxito prematuros en bucles de firmantes, añadiendo comentarios explícitos y aserciones invariantes que documenten el comportamiento esperado para cuentas no creadas en la validación, y revisando todas las ubicaciones del código donde ocurren retornos de éxito tempranos en bucles para confirmar que no existan patrones similares.
También anunció un reinicio programado del devnet para el 3 de marzo de 2026, para implementar estos cambios y evitar que los validadores que actualicen queden bloqueados por la enmienda. Este reinicio eliminará todos los datos del libro mayor del devnet, incluyendo cuentas, transacciones, saldos y otros registros, con todos los saldos reseteados a cero y el número de bloque reiniciado en uno. La red principal, XRPL Testnet, Xahau y la red de Hooks continuarán operando normalmente sin interrupciones.
Preguntas Frecuentes: Entendiendo la Vulnerabilidad en la Enmienda por Lotes del XRPL
Q: ¿Qué se suponía que hacía la enmienda por lotes en XRP Ledger?
A: La enmienda por lotes era una función propuesta que permitía la ejecución atómica de hasta ocho transacciones en una sola operación por lotes. Permitía a los desarrolladores construir aplicaciones con funciones de pago, flujos de trabajo automatizados y modelos de ingresos en cadena, asegurando que múltiples transacciones se ejecutaran juntas, todas con éxito o todas fallidas.
Q: ¿Cómo podrían los atacantes explotar esta vulnerabilidad?
A: Los atacantes podían construir una transacción por lotes con un pago que creara una cuenta nueva, una transacción desde esa cuenta y un pago desde una cuenta víctima. Aprovechando un fallo donde la validación salía temprano al encontrar un firmante de una cuenta inexistente, podían omitir la verificación de firma en el pago de la víctima y drenar fondos sin poseer las claves privadas de la víctima.
Q: ¿Por qué no se perdió dinero en este incidente?
A: La enmienda por lotes aún estaba en fase de votación y no se había activado en la red principal cuando se descubrió la vulnerabilidad. La Fundación XRPL aconsejó inmediatamente a los validadores votar en contra y emitió una versión de software de emergencia (rippled 3.1.1) que la desactivó por completo, impidiendo cualquier activación.
Q: ¿Qué papel jugó la IA en el descubrimiento de esta vulnerabilidad?
A: La herramienta autónoma de IA de Cantina, Apex, identificó la vulnerabilidad mediante análisis estático del código rippled. Su descubrimiento, junto con el análisis de ingenieros de seguridad humanos, permitió una divulgación responsable y la corrección antes de que la enmienda pudiera activarse, demostrando la creciente importancia de las herramientas de ciberseguridad impulsadas por IA.