Vulnerabilidad en XRPL: validadores frenaron un exploit silencioso que vaciaba cuentas solo con comisiones

Los validadores del XRP Ledger neutralizaron una vulnerabilidad en XRPL que, de haberse activado, permitía drenar los fondos de una cuenta ajena únicamente a través de las comisiones de transacción, sin necesidad de firmar movimientos de dinero ni acceder a las claves de la víctima. El fallo quedó desactivado porque las funciones implicadas siguen marcadas por defecto como no habilitadas y el mecanismo de votación de la red permanece inactivo.

El problema no residía en un contrato malicioso ni en un robo de credenciales, sino en la mecánica de las fees. Bajo ciertas combinaciones de funciones aún no activadas en la red principal, un atacante podía forzar el cobro repetido de comisiones a una cuenta objetivo hasta agotar su saldo, un vector especialmente peligroso por lo discreto: no dejaba el rastro habitual de una transferencia no autorizada.

Cómo se contuvo la vulnerabilidad en XRPL

La contención se apoya en el diseño de gobernanza del propio ledger. En el XRP Ledger, los cambios de protocolo se introducen mediante amendments (enmiendas), que solo entran en vigor cuando alcanzan el respaldo de una supermayoría de validadores —el 80%— sostenida durante dos semanas seguidas. Mientras ese reloj no se pone en marcha, las funciones quedan en estado «No» por defecto y no producen efecto sobre la red.

Publicidad

Ese es justamente el caso de BatchV1_1 y PermissionDelegationV1_1, las dos funciones cuya interacción abría la puerta al exploit. Ambas continúan marcadas como no habilitadas y el contador de dos semanas de la supermayoría permanece detenido, según se recoge en la divulgación oficial del XRP Ledger. Dicho de otro modo, el fallo se corrigió antes de que pudiera existir en producción.

La lógica de estas enmiendas y su umbral de activación están descritos en la documentación pública sobre reglas de amendments, un procedimiento pensado precisamente para evitar que cambios sensibles se cuelen sin consenso amplio de los operadores de nodos.

Parches, versiones y ventana de exposición

La corrección se canalizó a través del software de nodo rippled. El equipo de desarrollo publicó la versión rippled 3.2.1 y trasladó los ajustes a las ramas de desarrollo posteriores, con builds en fase beta y release candidate para la serie 3.3. La revisión del registro de funciones en desarrollo confirma que las capacidades problemáticas no se activarán hasta que el código endurecido esté ampliamente desplegado.

Este episodio llega poco después de que el ledger recibiera la actualización 3.2.1 para corregir el fallo de inundación de manifiestos en sus nodos, otra reparación de fontanería técnica que, como la actual, se resolvió sin incidentes visibles para el usuario final.

El patrón se repite: una vulnerabilidad se documenta, se parchea y se divulga después de que el riesgo esté neutralizado. El XRP Ledger ya había publicado un informe similar en septiembre de 2025, disponible en su divulgación previa, lo que sugiere un proceso de reporte responsable ya rodado dentro del proyecto.

Por qué importa para el ecosistema y los usuarios

Para los tenedores de XRP, la lectura de fondo es tranquilizadora en lo inmediato: no hubo fondos comprometidos ni una explotación real en la red principal. El vector nunca llegó a ser operativo porque dependía de funciones que jamás pasaron el filtro de la supermayoría de validadores.

El caso ilustra, sin embargo, una tensión constante en el desarrollo de blockchains: las nuevas capacidades —en este caso el procesamiento por lotes de transacciones y la delegación de permisos— amplían lo que se puede hacer sobre el ledger, pero también multiplican las combinaciones posibles y, con ellas, las superficies de ataque no previstas. La gobernanza por enmiendas actúa como una red de seguridad que ralentiza a propósito la adopción de cambios sensibles.

La diferencia con otros sustos recientes del sector es notable. Mientras que el fallo en las billeteras COLDCARD derivó en pérdidas reales para usuarios de Bitcoin, aquí el diseño de la red evitó que el problema llegara a materializarse.

Queda por delante lo que suele ser la parte más lenta: que los operadores de nodos actualicen a las versiones corregidas y que cualquier futura activación de BatchV1_1 y PermissionDelegationV1_1 se produzca únicamente sobre software ya blindado. Mientras el reloj de la supermayoría siga detenido, el exploit descrito seguirá siendo una hipótesis que nunca ocurrió.