Al XRP Ledger le encontraron un fallo que dejaba firmar por cualquier cuenta y no perdió un dólar, y esa función vuelve a votación la semana que viene

La próxima versión del servidor del XRP Ledger, la xrpld 3.3.0, llega la semana que viene con cinco cambios de protocolo para que los validadores los voten. Dos de ellos ya pasaron por esa votación y no la superaron: a uno le encontraron un fallo que permitía ejecutar transacciones desde cualquier cuenta sin tener sus claves, y al otro uno que dejaba cargar comisiones a una cuenta ajena hasta dejarla seca. Ninguno de los dos llegó nunca a la red principal, y las pérdidas fueron de cero dólares.

Esa cifra es lo interesante, no el calendario. Esta misma semana, un fallo del generador de números aleatorios de las carteras Coldcard se ha llevado unos 70 millones de dólares en bitcoin después de cinco años vivo en el firmware. Los dos errores del XRP Ledger eran de la misma familia, un despiste dentro de una función que nadie mira con lupa, y no costaron nada. La diferencia no está en la calidad del código.

Los cinco cambios, y por qué los nombres no son los de antes

Jazzi Cooper, responsable de producto de RippleX, anunció el viernes que la 3.3.0 llega con Confidential MPT, Batch, Permission Delegation, Sponsored Fees and Reserves y Dynamic MPT. Una enmienda en el XRP Ledger no entra en vigor porque la publique Ripple: necesita el respaldo de al menos el 80% de los validadores de confianza durante dos semanas consecutivas.

Hay un detalle que ninguna crónica ha recogido y que está en el propio registro de enmiendas de xrpl.org: las enmiendas llamadas Batch y PermissionDelegation siguen en la lista de obsoletas, con un aviso de que serán sustituidas por BatchV1_1 y PermissionDelegationV1_1. Lo que se vota, entonces, no es la vuelta de las funciones retiradas, sino enmiendas nuevas con identificadores nuevos. Las que fallaron se quedan muertas para siempre, y eso es deliberado: un validador que se hubiera quedado atrás no puede activar por accidente la versión mala.

Dos de los tres estrenos merecen una lectura aparte. Sponsored Fees permite que un usuario opere sin comprar nunca XRP, porque otro le cubre la comisión y la reserva mínima de la cuenta: la cadena cuyo motivo de existir es su moneda está construyendo la pieza que hace innecesario tenerla. Y Confidential MPT esconde saldos e importes pero deja una puerta para que auditores y reguladores verifiquen cuando toca, tres días después de que Zcash sellara la piscina que nadie pudo auditar. Son dos respuestas opuestas a la misma pregunta.

El fallo del Batch: una cuenta que todavía no existía

El 19 de febrero de 2026, Pranamya Keshkamat y Apex, la herramienta autónoma de seguridad de Cantina AI, encontraron el error mediante análisis estático del código de rippled. Dentro de un lote, las transacciones internas van a propósito sin firmar y la autorización se delega en la lista de firmantes del lote exterior. La función que validaba esa lista tenía un error de bucle: cuando se topaba con un firmante cuya cuenta aún no existía en el ledger y cuya clave de firma coincidía con su propia cuenta, que es el caso normal de una cuenta recién creada, daba la validación por buena y salía, sin comprobar ninguno de los firmantes restantes.

El camino de explotación que describe el informe de divulgación tiene tres pasos. El atacante monta un lote con tres transacciones internas: una que crea una cuenta nueva bajo su control, una operación trivial desde esa cuenta para convertirla en firmante obligatorio, y un pago de la cuenta víctima hacia él. Aporta dos entradas de firmante, la legítima de su cuenta nueva y una falsificada que dice autorizar a la víctima pero está firmada con su propia clave. Como la cuenta nueva no existe en el momento de la validación, la comprobación termina con éxito en la primera entrada y nunca llega a la segunda. El pago de la víctima se ejecuta sin que sus claves aparezcan en ningún sitio.

Si la enmienda hubiera estado activa, el informe admite que se podían vaciar cuentas hasta la reserva y enviar AccountSet, TrustSet y potencialmente AccountDelete desde cuentas ajenas. No pasó nada de eso. Los ingenieros reprodujeron el fallo esa misma tarde con una prueba de concepto y un test unitario, se avisó a los validadores de la lista de confianza de que votaran «no» y varios aplicaron el veto esa noche. El 23 de febrero salió la 3.1.1, que marca Batch y fixBatchInnerSigs como no soportadas para que no puedan ni recibir votos.

La comisión que se cobraba antes de mirar la firma

El segundo caso es más barato de explicar y más incómodo de leer. En septiembre de 2025, un miembro de la comunidad que firma como tequ encontró probando en devnet que Permission Delegation permitía vaciar una cuenta ajena a base de comisiones. El mecanismo, según el informe correspondiente: en una transacción delegada la comisión se cobra a la cuenta delegada, y el permiso se comprobaba antes que la firma. Si la cuenta no tenía el permiso, la operación fallaba con tecNO_DELEGATE_PERMISSION sin llegar a verificar la firma, y los errores de tipo tec están diseñados para cobrar comisión. Bastaba enviar una transacción con una comisión altísima y una firma válida pero no autorizada, firmándola sin conexión para que el nodo no la rechazara antes.

Cualquier error devuelto antes de la verificación de la firma no debe ser de tipo tec. La lógica de validación que pueda producir un error tec debe ejecutarse después de la verificación de la firma.

Esas son las dos reglas que Ripple escribió en el informe después del incidente, y el arreglo cabe en una letra: el código de error pasó de tec a ter. Lo caro no fue el parche, fue descubrir que el orden de dos comprobaciones es una decisión monetaria. Sobre esa lección se añadió algo más duradero, una comprobación de invariante que impide deducir cualquier comisión si la firma no se ha verificado, es decir, un guardia que no depende de que el siguiente desarrollador recuerde la regla.

La diferencia con los Coldcard son dos semanas de votos

El commit que rompió los Coldcard salió en el firmware v4.0.0 en marzo de 2021 y empezó a generar semillas predecibles el día que cada usuario lo instaló. Un firmware entra en vigor cuando lo enchufas. Una regla del XRP Ledger no entra en vigor hasta que el 80% de los validadores la sostiene catorce días seguidos, así que el código defectuoso del Batch estuvo publicado y a la vista, pero inerte. Ese hueco entre publicar y activar es lo único que separa un informe técnico de un titular con cifras.

Hay un segundo contraste que conviene no dejar pasar. El fallo del Batch lo cazó una herramienta de IA haciendo análisis estático. Coinkite contó ayer que hace unas semanas pasó uno de los mejores modelos de IA sobre su propio firmware y no encontró nada, y su fundador habla de «una realidad sobria del nuevo paradigma de la IA». La misma tecnología, resultados opuestos. La hoja de ruta de seguridad de xrpl.org ahora incluye las auditorías asistidas por IA como paso estándar de revisión y, más revelador, extender el análisis estático para detectar retornos de éxito prematuros dentro de bucles de firmantes. Cuando la lección que alguien escribe es así de específica, suele ser porque la aprendió de verdad.

La otra cara: el 80% no audita, solo retrasa

El umbral no detectó nada. Los validadores iban camino de aprobar el Batch y lo que los frenó fue un mensaje pidiéndoles que votaran «no». La detección vino de fuera en un caso y de un aficionado tocando devnet en el otro. El proceso compró tiempo, no encontró el error, y las dos veces funcionó porque alguien tenía línea directa con quienes votan: en septiembre el aviso salió por Mattermost hacia los validadores de la lista de confianza. Un mecanismo de seguridad que depende de un canal privado no es exactamente descentralizado.

La misma puerta que bloquea el código malo bloquea el bueno. Según CoinDesk, las enmiendas del protocolo de préstamos y de las bóvedas de activo único llevan reunido alrededor de un tercio del apoyo frente al 80% que necesitan, y el Batch ya carga con el antecedente de haber sido rechazado. Exigir una supermayoría también significa que una función puede no llegar nunca. A favor de Ripple hay que apuntar que ambos fallos se publicaron con camino de explotación y pasos para reproducirlos antes de que hubiera un solo dólar en riesgo, algo que muy pocas cadenas hacen. El mercado, mientras tanto, no se ha dado por enterado: XRP cotiza a 1,06 dólares con una caída del 1,5% en 24 horas, en línea con un bitcoin a 63.012 dólares.

Qué hay que vigilar

Datos: informes de divulgación de vulnerabilidades de xrpl.org (febrero de 2026 y septiembre de 2025), registro de enmiendas de xrpl.org, anuncio de Jazzi Cooper (RippleX), CoinDesk, U.Today, TokenPost.