1/4
Resumen del Ataque
El 15 de septiembre de 2026, una grave vulnerabilidad de bypass de autorización dentro de un ejecutor de estrategias provocó el vaciado de la billetera #Safe de una persona de alto patrimonio. Este incidente derivó en una pérdida aproximada de 7,8M USD.
Comprender la causa raíz
La vulnerabilidad se aisló en un ejecutor de estrategias no verificado ubicado en la dirección del contrato 0x4f0055926c839D1d960a82CBF84E2eE933958ebC. Es importante recalcar que este fallo no se encontró en el protocolo central de Safe, ni se originó en Aave o rsETH.
Bajo condiciones normales de operación, el sistema dicta que el objetivo debe ser un Safe aprobado y en la lista permitida (allowlist), y que msg.sender debe ser un Módulo específicamente habilitado por ese Safe. Sin embargo, el sistema permitió que cualquier llamador externo eludiera estas dos comprobaciones esenciales de seguridad simplemente asignando el objetivo como address(this), que apunta de vuelta al propio ejecutor.
Una vez eludidas estas verificaciones, el actor malicioso ejecutó un DELEGATECALL mediante un Módulo de Safe que ya había sido habilitado. Esto permitió al atacante procesar lógica arbitraria directamente dentro del contexto del Safe de la víctima.
La secuencia del ataque
Durante la ejecución del exploit, el atacante transfirió aproximadamente 2.900 aEthrsETH a un pool de liquidez de Uniswap v4, emparejando los activos contra un token PAT que no tiene ningún valor. Como resultado, el Safe comprometido se quedó sin sus activos reales, dejando a la víctima únicamente con inútiles NFT de LP.
Curiosamente, la transacción original del ataque no salió exactamente como el hacker planeó. Un bot de MEV conocido como Yoink logró adelantarse (front-run), interceptó la transacción y se llevó toda la pila de rsETH.
Resumen del Ataque
El 15 de septiembre de 2026, una grave vulnerabilidad de bypass de autorización dentro de un ejecutor de estrategias provocó el vaciado de la billetera #Safe de una persona de alto patrimonio. Este incidente derivó en una pérdida aproximada de 7,8M USD.
Comprender la causa raíz
La vulnerabilidad se aisló en un ejecutor de estrategias no verificado ubicado en la dirección del contrato 0x4f0055926c839D1d960a82CBF84E2eE933958ebC. Es importante recalcar que este fallo no se encontró en el protocolo central de Safe, ni se originó en Aave o rsETH.
Bajo condiciones normales de operación, el sistema dicta que el objetivo debe ser un Safe aprobado y en la lista permitida (allowlist), y que msg.sender debe ser un Módulo específicamente habilitado por ese Safe. Sin embargo, el sistema permitió que cualquier llamador externo eludiera estas dos comprobaciones esenciales de seguridad simplemente asignando el objetivo como address(this), que apunta de vuelta al propio ejecutor.
Una vez eludidas estas verificaciones, el actor malicioso ejecutó un DELEGATECALL mediante un Módulo de Safe que ya había sido habilitado. Esto permitió al atacante procesar lógica arbitraria directamente dentro del contexto del Safe de la víctima.
La secuencia del ataque
Durante la ejecución del exploit, el atacante transfirió aproximadamente 2.900 aEthrsETH a un pool de liquidez de Uniswap v4, emparejando los activos contra un token PAT que no tiene ningún valor. Como resultado, el Safe comprometido se quedó sin sus activos reales, dejando a la víctima únicamente con inútiles NFT de LP.
Curiosamente, la transacción original del ataque no salió exactamente como el hacker planeó. Un bot de MEV conocido como Yoink logró adelantarse (front-run), interceptó la transacción y se llevó toda la pila de rsETH.
