Una falla de seguridad en una actualización propuesta de XRP Ledger (XRPL) podría haber permitido transacciones no autorizadas, pero los investigadores señalaron el problema antes de que pudiera llegar a la red principal de blockchain.
La Fundación XRPL dicho El 26 de febrero se informó que la vulnerabilidad se encontró en la enmienda propuesta “Batch”, una característica destinada a permitir a los usuarios agrupar múltiples acciones en una sola transacción atómica.
El investigador de seguridad Pranamya Keshkamat y la herramienta autónoma de análisis estático de Cantina AI, Apex, informaron sobre el problema el 19 de febrero, según la fundación.
Si la enmienda se hubiera activado con el error implementado, un atacante podría haber ejecutado transacciones internas como si estuvieran autorizadas por otra cuenta, sin acceso a las claves privadas de ese usuario.
Eso podría haber permitido transferencias de fondos no autorizadas y cambios en la configuración del libro mayor en la cuenta de la víctima, aunque la víctima no firmó la transacción.
La divulgación se produce cuando XRPL se ha estado posicionando para casos de uso como la tokenización y otras actividades sensibles al cumplimiento, donde la seguridad y confiabilidad percibidas son fundamentales para la adopción institucional.
Comprender la falla de seguridad crítica de la enmienda por lotes de XRPL
La enmienda por lotes propuesta cambió la forma en que funcionaría la autorización en el XRP Ledger al permitir que múltiples transacciones “internas” se agrupen en una única transacción por lotes “externa”, de modo que todos los pasos tengan éxito o fracasen juntos.
Esa estructura atómica puede reducir el riesgo de ejecución para los desarrolladores que ejecutan operaciones de varios pasos. También crea un nuevo límite de autorización.
En el diseño por lotes, las transacciones internas no están firmadas intencionalmente. En cambio, la autoridad se delega a una lista de firmantes por lotes adjunta a la transacción externa, lo que convierte al código de validación del firmante en un punto de control crítico.
Si esas comprobaciones fallan, el libro mayor puede tratar las acciones no autorizadas como válidas.
La divulgación decía que el error se debía a un error de bucle en la función que valida los firmantes por lotes.
Cuando el código encontró un firmante cuya cuenta aún no existía en el libro mayor y cuya clave de firma coincidía con esa misma cuenta, un estado normal para una cuenta recién creada, devolvió el éxito inmediatamente y dejó de verificar el resto de la lista de firmantes.
Esa condición era más peligrosa de lo que parece en un sistema de procesamiento por lotes. Un lote puede incluir pasos que crean cuentas dentro de la misma secuencia atómica, lo que significa que si una cuenta existe en el momento de la validación pasa a formar parte del límite de autorización.
El informe decía que un atacante podría haber insertado una entrada de firmante válida para una cuenta aún no creada que controlaba, desencadenar la condición de éxito prematuro y omitir la validación de una entrada de firmante falsificada que afirmaba autorizar una cuenta de víctima.
Si Batch se hubiera activado antes de que se detectara la falla, las consecuencias podrían haber sido graves.
La Fundación dijo que un atacante podría haber ejecutado transacciones de pago internas que drenaron las cuentas de las víctimas hasta la reserva. El mismo error también podría haber permitido operaciones no autorizadas a nivel de cuenta, incluidas AccountSet, TrustSet y potencialmente AccountDelete.
Eso habría equivalido a un escenario de “gasto sin claves”, el tipo de falla de seguridad que puede causar daños a la reputación incluso si las pérdidas son limitadas y abordadas rápidamente.
La falla podría haber destrozado el barniz de seguridad de XRPL
La falla podría haber dañado la narrativa de seguridad de XRPL en un momento delicado para la red, que se está expandiendo agresivamente hacia la tokenización de activos del mundo real (RWA) y DeFi institucional.
Los datos de DeFiLlama muestran que XRPL tiene alrededor de $50 millones en valores totales de DeFi bloqueados en la plataforma, con casi $2 mil millones en activos RWA.
En los criptomercados, las fallas de autorización a menudo moldean la percepción mucho después de que se resuelve el problema técnico subyacente.
Para un libro mayor que se posiciona como infraestructura para las finanzas reguladas, un incidente así habría tenido implicaciones más amplias.
Esto es especialmente cierto teniendo en cuenta que XRPL introdujo recientemente un nuevo conjunto de características centradas en las instituciones, incluidos dominios autorizados y DEX.
Estas funciones están diseñadas para crear lugares de negociación cerrados donde sólo los participantes aprobados pueden realizar y recibir órdenes. El modelo está dirigido a instituciones que desean una liquidación basada en blockchain sin acceso abierto a todas las contrapartes.
Por lo tanto, la cuestión de seguridad habría socavado ese mensaje. Una red no puede ser fácilmente controlada por el mercado o centrada en el cumplimiento en entornos en cadena, mientras que una actualización de transacción propuesta conlleva el riesgo de acciones no autorizadas que involucren cuentas arbitrarias.
Cómo XRPL evitó el incidente de seguridad
La respuesta de XRPL avanzó rápidamente a través de canales de gobernanza y software.
Se contactó a la Lista de Nodos única (UNL) de validadores confiables y se les recomendó votar “No” a la enmienda del Lote.
El 23 de febrero, XRPL publicó rippled 3.1.1, una versión de emergencia que marca tanto a Batch como a fixBatchInnerSigs como no compatibles. Eso impidió que las enmiendas recibieran votos de validación o se activaran en la red.
La liberación fue diseñada como una contención inmediata, no como una reparación completa. La divulgación indica explícitamente que la versión 3.1.1 no incluye la solución lógica subyacente.
XRPL también programó un reinicio de devnet para el 3 de marzo de 2026, para coincidir con el cambio 3.1.1. Ese reinicio se aplica únicamente a Devnet, no a mainnet, pero muestra hasta qué punto los operadores de la red actuaron para evitar que el problema afectara las rutas de enmienda activas.
Ya se implementó un reemplazo corregido, BatchV1_1, que se encuentra bajo revisión, sin fecha de lanzamiento establecida.
Según la divulgación, la solución completa elimina la salida anticipada, agrega protecciones de autorización adicionales y reduce el alcance de la verificación de firmas.
El informe también presentó una hoja de ruta de seguridad más amplia, que incluye auditorías asistidas por IA más estandarizadas, comprobaciones ampliadas de análisis estático para detectar salidas de bucles peligrosas y una revisión de patrones similares en otras partes del código base.
La siguiente prueba es enviar el reemplazo de forma segura.
Para XRPL, el resultado de febrero contará como un éxito de gobernanza. El error se encontró antes de la activación. Validadores coordinados. Una liberación de emergencia bloqueó el camino de la enmienda. No se perdieron fondos.
Pero la historia no termina ahí.
BatchV1_1 ahora se evaluará en dos niveles. La primera es técnica, si ofrece al desarrollador los beneficios de la agrupación de transacciones atómicas sin riesgo de autorización de reapertura.
El segundo es de procedimiento, si los sistemas de ingeniería y gobernanza de XRPL pueden seguir el ritmo de un conjunto de características en expansión destinado a la adopción institucional.
Ese es el verdadero telón de fondo de este casi accidente. XRPL está tratando de convertirse en una plataforma financiera más amplia, que pueda albergar lugares de negociación cerrados, entornos autorizados y una lógica de transacciones más sofisticada, al tiempo que atrae a constructores con capital de ecosistema y amplitud de productos.
Cuanto más ambiciosa se vuelve esa hoja de ruta, más importantes se vuelven las cosas aburridas como la validación del firmante y el comportamiento del bucle.
En este caso, los frenos funcionaron. El próximo desafío es demostrar que el sistema puede acelerar nuevamente sin perder ese margen de seguridad.