XRPL corrige la delegación de permisos tras descubrirse un error crítico

XRPL retiró su enmienda sobre delegación de permisos después de que un informe de recompensas por errores detectara una vulnerabilidad de alto riesgo durante las pruebas. Ahora, una versión V1.1 reforzada está completando la revisión de seguridad y las comprobaciones de control de calidad.

Este episodio muestra por qué la delegación a nivel de protocolo necesita protecciones que vayan más allá de la función básica en sí.

XRPL rediseña la delegación de permisos tras un informe de errores

La delegación de permisos, conocida como XLS-75, permite que una cuenta otorgue a otra permisos específicos para actuar en su nombre. Se espera que los permisos sean limitados, en lugar de dar al delegado el control de toda la cuenta.

J. Ayo Akinyele, responsable de ingeniería de RippleX, explicó que la implementación original V1.0 se retiró después de que se notificara una vulnerabilidad a través del programa de recompensas por errores, antes de que llegara a la red principal de XRPL. En vez de aplicar un parche a esa versión, el equipo presentó V1.1 para separar la implementación original de la versión reforzada.

Un investigador llamado Shotes encontró un problema de gravedad alta relacionado con permisos de delegado irrevocables. Un delegado podía eliminar su cuenta y volver a crearla más tarde conservando los permisos que otra cuenta le había otorgado, sin que la cuenta original pudiera revocarlos.

Los cambios van más allá de un único error. V1.1 aborda casos límite relacionados con la identidad de los delegados e impide que capacidades más recientes, incluidas las operaciones de Vault y Lending, se deleguen sin querer. También corrige la contabilidad de reservas para los pagos delegados y cierra una vía de firma múltiple que podía eludir las comprobaciones de delegación. Además, se reforzó el comportamiento de revocación.

La revisión también detectó un desbordamiento de entero sin signo de gravedad media en isDelegable, que podía hacer que un valor de permiso malformado se interpretara como un tipo de transacción delegable, aunque los investigadores afirmaron que el problema no tenía un impacto significativo si el delegador no actuaba de forma indebida.

Las pruebas se amplían a todo el ámbito de delegación de XRPL

Un informe de control de calidad publicado por Ramkumar SG el 26 de agosto registró 179 pruebas específicas de Permission Delegation, incluidas 112 pruebas funcionales, 48 pruebas de seguridad adversariales y 19 pruebas entre funciones. También se probaron las interacciones con Batch, Confidential MPT, la cola de transacciones y la firma múltiple.

XRP Ledger Operations afirmó que todos los hallazgos se habían corregido en V1.1 y que la firma de seguridad Cantina los había verificado. Su equipo de control de calidad también informó que no hubo regresiones en 5.088 pruebas y señaló que no quedaban errores internos abiertos clasificados como críticos; concluyó que la función estaba lista para su uso en producción en el nivel de commit probado.

La Delegación de permisos se introdujo en mayo de 2025, se marcó como no compatible en septiembre de 2025 a la espera de una solución de seguridad, pasó a llamarse PermissionDelegationV1_1 en octubre y volvió a ser compatible en junio de 2026.

Como CryptoPotato informó la semana pasada que un panel público creado por el desarrollador Denis Angell ha estado registrando con qué exhaustividad se prueban las enmiendas de XRPL en devnet antes de llegar a mainnet, y que la delegación figuraba entre las enmiendas que había marcado como incompletas.

Para los usuarios y los proveedores de custodia, la capacidad prevista sigue sin cambios. Como señaló Akinyele, la V1.1 no cambia lo que XLS-75 puede hacer; cambia las condiciones en las que se activa esa capacidad.

Fuente: CryptoPotato