La Fundación Radix informó el 17 de septiembre de que una vulnerabilidad introducida durante una refactorización de código de Radix Engine en 2023 fue explotada el 31 de agosto de 2026. Los atacantes retiraron aproximadamente 1,26 millones de dólares de varios vaults, lo que llevó a los validadores de Radix a detener temporalmente el consenso y suspendió las transacciones de la red durante más de 10 días.
El incidente afectó a un ámbito más amplio que los activos robados directamente. Los investigadores determinaron que, en teoría, el fallo podía haberse utilizado contra cualquier vault de la red, incluidos los tokens depositados en cuentas de usuarios, aplicaciones y pools de liquidez. Para las plataformas de negociación y los proveedores de liquidez, el problema central fue que la capa de ejecución no aplicó correctamente los límites de permisos diseñados para proteger los activos de los vaults.
26 transacciones movieron varios activos
La reconstrucción del registro comunitario muestra que el atacante ejecutó 26 transacciones de explotación entre las 16:02 y las 16:57 UTC del 31 de agosto. En ellas movió aproximadamente 458.915 USDC, 72.420 USDT, 61,08 ETH, 6,35 Wrapped Bitcoin, 536,16 SOL y 32,91 BNB. Según los precios de mercado del 31 de agosto, el valor conjunto rondaba los 1,26 millones de dólares; las dos stablecoins representaban unos 531.300 dólares.
El atacante también retiró 13.000 XRD de un vault para pagar las comisiones de las transacciones. Después transfirió los activos sustraídos mediante Hyperlane a Ethereum, BNB Chain y Solana, donde fueron convertidos en ETH. La Fundación Radix indicó que el puente Hyperlane funcionó conforme a su diseño: los activos se obtuvieron primero mediante Radix Engine y solo después se utilizó el servicio entre cadenas para moverlos. Por el momento, no hay indicios de que se comprometieran claves privadas.
El importe transferido podría no reflejar todo el impacto económico. Los investigadores señalaron que el fallo no se limitaba a los activos entre cadenas retirados directamente por el atacante. Otros tokens y activos depositados en vaults de toda la red también podían haber estado expuestos al mismo riesgo.
Una refactorización de 2023 introdujo el fallo
La Fundación Radix afirmó que el defecto fue introducido por el equipo de desarrollo de RDX Works en junio de 2023, durante una limpieza del código de Radix Engine. La vulnerabilidad permaneció en la red durante más de tres años antes de ser explotada el 31 de agosto de 2026.
El problema estaba relacionado con la forma en que el motor gestionaba las referencias a los vaults. Una transacción podía utilizar una dirección interna para apuntar al vault de otro usuario y pasar esa referencia a un contrato inteligente concreto. Radix Engine permitía entonces invocar una función estándar de retirada sin aplicar correctamente la comprobación de titularidad del vault, por lo que no rechazaba una solicitud no autorizada.
Según el diseño previsto, solo el propietario de un vault o una transacción autorizada puede retirar sus activos. El defecto podía permitir que un atacante accediera a fondos de cuentas de usuarios, aplicaciones y pools de liquidez sin obtener la firma del titular de los activos.
El código también había superado una revisión de seguridad independiente. Zellic auditó el protocolo Radix en 2024, incluido el núcleo de Engine donde se encontraba el defecto, pero no detectó la vulnerabilidad de autorización. Al haberse originado el problema en una refactorización anterior, el incidente puso de relieve que las tareas rutinarias de mantenimiento pueden modificar supuestos de seguridad existentes de una forma que las auditorías convencionales no siempre identifican.
Los validadores detuvieron el consenso
Una vez confirmado que el problema estaba en la capa de ejecución de transacciones y no en una aplicación concreta, los validadores de Radix coordinaron la respuesta. Retiraron voluntariamente una cantidad suficiente de participación para impedir que la red alcanzara el consenso y procesara nuevas transacciones.
La interrupción duró más de 10 días. La actualización del protocolo incorporó comprobaciones para impedir que referencias restringidas a vaults se utilizaran con funciones estándar de retirada. La reconstrucción del registro comunitario indica que las transacciones de los usuarios se reanudaron el 11 de septiembre.
El incidente también generó pérdidas secundarias en pools de liquidez. Después de que el atacante retirara activos entre cadenas de uno de los lados de varios pares de negociación, las proporciones de precios de los pools quedaron distorsionadas. Otra cuenta aprovechó esos precios anómalos para retirar millones de XRD de los pools afectados. El episodio mostró que, incluso después de que los activos robados inicialmente hayan salido de la red, una vulnerabilidad en la capa de ejecución puede seguir provocando pérdidas mediante distorsiones de precios y cambios en las condiciones de liquidez.
Radix ampliará las pruebas y los protocolos de emergencia
La Fundación Radix señaló que sus medidas posteriores incluirán la ampliación de las pruebas de regresión, el refuerzo de los procedimientos de revisión de seguridad y la institucionalización formal de las acciones de emergencia adoptadas por los validadores para restablecer la seguridad de la red. El trabajo no se limitará a cerrar la ruta de código explotada; también revisará todos los cambios que afecten a la lógica de autorización.
La Fundación añadió que el trabajo de seguridad futuro deberá tener en cuenta unas herramientas de análisis de código asistidas por inteligencia artificial cada vez más capaces, que podrían ayudar a los atacantes a localizar fallos antiguos. La comunicación del incidente no determinó si el atacante utilizó alguna herramienta concreta.
Para los desarrolladores y validadores, la prioridad inmediata es garantizar que el mantenimiento rutinario no altere el modelo de permisos sin pruebas y revisiones suficientes. Para los usuarios y proveedores de liquidez, las cuestiones principales siguen siendo si la red aplica de forma constante las comprobaciones de titularidad de los vaults y si los procedimientos de emergencia revisados pueden activarse con rapidez ante un incidente similar. Estos factores estarán vinculados a la confianza en la seguridad de los activos de Radix y en la estabilidad de la red.