Una vulnerabilidad introducida durante una limpieza rutinaria del código de Radix permitió sustraer activos por valor aproximado de 1,26 millones de dólares y obligó a detener la finalización de transacciones de la red durante más de 10 días. El fallo permaneció sin detectar durante más de tres años, hasta que fue explotado el 31 de agosto.
La Radix Foundation explicó el 17 de septiembre que un equipo de desarrollo de RDX Works introdujo el defecto en junio de 2023, al revisar el Radix Engine. Esta capa de software ejecuta las transacciones y aplica las reglas de propiedad de los activos en la red.
Un fallo en las referencias de las bóvedas
El problema afectaba a la forma en que el motor gestionaba las referencias a las bóvedas, los contratos que custodian tokens y otros activos. Una transacción podía identificar una bóveda ajena mediante su dirección interna y entregar esa referencia a un contrato inteligente diseñado para ejecutar operaciones específicas.
En determinadas circunstancias, el motor permitía entonces utilizar funciones normales de retirada sin comprobar correctamente que quien solicitaba la operación era el propietario. El atacante podía acceder así a fondos de cuentas de usuarios, aplicaciones y fondos de liquidez sin disponer de las firmas de sus titulares.
La reconstrucción del registro realizada por la comunidad atribuye al atacante 26 transacciones, ejecutadas entre las 16:02 y las 16:57 UTC del 31 de agosto. En ellas retiró aproximadamente 458.915 USDC, 72.420 USDT, 61,08 ETH, 6,35 bitcoins envueltos, 536,16 SOL y 32,91 BNB. Según los precios de mercado de ese día, el valor conjunto rondaba los 1,26 millones de dólares.
Los dos activos estables representaban por sí solos unos 531.335 dólares. Además, el atacante extrajo otros 13.000 XRD de una bóveda para pagar las comisiones de las transacciones.
Los validadores detuvieron la red
Los activos robados se enviaron a través de Hyperlane hacia Ethereum, BNB Chain y Solana, donde fueron intercambiados por ETH, según Radix. La fundación subrayó que el puente funcionó como estaba previsto: los fondos ya habían sido obtenidos de forma ilegítima dentro de Radix antes de ser trasladados a otras redes. El incidente tampoco implicó el compromiso de claves privadas.
La cantidad sustraída no reflejaba, sin embargo, todo el riesgo. Los investigadores concluyeron que el fallo podía utilizarse contra cualquier bóveda de la red, incluidos activos distintos de los que llegaron a ser atacados. Para limitar la exposición, los validadores retiraron deliberadamente suficiente participación como para impedir que la red alcanzara el consenso y siguiera procesando transacciones.
La paralización se prolongó durante más de 10 días. El arreglo incorporó comprobaciones para impedir que una referencia restringida a una bóveda se utilizara en una retirada ordinaria. La reconstrucción comunitaria del registro sitúa en el 11 de septiembre la reanudación de las transacciones de los usuarios.
El episodio también provocó pérdidas posteriores en fondos de liquidez. Al retirar el atacante activos que formaban parte de uno de los lados de varios pares, los precios se desequilibraron. Otra cuenta pudo aprovechar esa distorsión para extraer millones de XRD de los fondos afectados, una muestra de cómo un fallo en la capa de ejecución puede seguir generando daños después del robo inicial.
El defecto superó una auditoría de seguridad
La vulnerabilidad había pasado además por una revisión independiente. Zellic auditó en 2024 el protocolo de Radix, incluido el núcleo del motor donde se encontraba el código defectuoso, pero no identificó el problema de autorización introducido durante la refactorización del año anterior.
Radix ha anunciado nuevas pruebas de regresión, un refuerzo de sus procesos de revisión y la formalización del procedimiento de emergencia empleado por los validadores para interrumpir la actividad de la red. La fundación también señaló que los futuros análisis deberán tener en cuenta herramientas de revisión de código asistidas por inteligencia artificial, que, en su opinión, podrían haber ayudado al atacante a localizar un fallo antiguo.
El reto para el proyecto no se limita a corregir la función vulnerable. También pasa por revisar cómo los cambios de mantenimiento pueden alterar, sin ser detectados por una auditoría externa, las reglas de autorización de las bóvedas y recuperar la confianza de usuarios y proveedores de liquidez.
