Las firmas de seguridad blockchain Blockaid, PeckShield y BlockSec confirmaron un exploit que drenó aproximadamente $7.8 millones en rsETH —alrededor de 2,900 tokens— de una Gnosis Safe wallet en Ethereum. Safe es una wallet de contratos inteligentes ampliamente utilizada para proteger grandes tenencias on-chain, y rsETH es el token de restaking líquido emitido por KelpDAO, una representación intercambiable de activos restaked. Según los reportes de las firmas, el incidente comenzó a las 04:38 UTC del 15 de septiembre con una transacción que movió la mayor parte de los fondos, seguida de varias transacciones menores durante la siguiente hora por un total adicional de ~$160,000.

Una verificación de autorización defectuosa permitió la ejecución arbitraria

La causa raíz fue una verificación de autorización defectuosa en el contrato executor, identificado por los analistas como la dirección 0x4f0055926c839D1d960a82CBF84E2eE933958ebC. La Safe atacada, que pertenecía a un gran tenedor de rsETH apalancado, dependía de un módulo strategy executor incluido en la lista blanca que exponía un entrypoint de recipe. Este entrypoint reenvió calldata suministrado completamente por el llamante a la función execTransactionFromModuleReturnData de la Safe usando operation=1 (DELEGATECALL) —una operación que permite que el código llamado se ejecute dentro del contexto del propio llamante— sin restringir al llamante externo. Establecer el parámetro de contrato suministrado en la dirección del propio executor superó la validación, lo que significaba que cualquier persona que pudiera alcanzar el entrypoint podía ejecutar código arbitrario dentro de la Safe, obteniendo efectivamente el control total sobre sus activos.

El atacante utilizó un multicall de keeper público para enrutar el módulo autorizado Uni V4 LP Safe hacia un pool de Uniswap V4 con hook creado por el atacante, ejecutando mediante Permit2 y el PositionManager. Como parte de la preparación, el atacante desplegó un token sin valor denominado "Permissionless Attacker Token" (PAT) y aportó aproximadamente 2,900 aEthrsETH como liquidez contra él. Un hook personalizado en el pool luego convirtió el aEthrsETH en rsETH y lo sustrajo de la Safe, que quedó reteniendo un LP NFT sin valor.

Blockaid exploit detection system detected an exploit on an unidentified user's Safe on Ethereum. ~$7.73M confirmed rsETH loss so far. An attacker used a public keeper multicall to drive a custom Uni V4 LP Safe module into an attacker-created hooked pool; the hook unw…

— Blockaid (@blockaid_) 15 de septiembre de 2026

Un bot MEV adelanta el ataque; KelpDAO impone una pausa temporal

Cabe destacar que la transacción de ataque original nunca llegó a su beneficiario previsto. El atacante lanzó el exploit directamente en la mempool pública, donde fue adelantado por un bot MEV llamado "yoink", que capturó la totalidad de los ~2,882 rsETH —con un valor aproximado de $7.8 millones— y los envió a la dirección 0xC70f00CD7E461686b04B0E912E309becA8b80ea0. En efecto, un bot de valor extractable máximo —un programa que captura valor explotando el ordenamiento de las transacciones dentro de un bloque— y no el atacante, se quedó con los fondos robados.

En respuesta, KelpDAO anunció que había detectado actividad sospechosa en la dirección receptora y la colocó bajo una pausa preventiva de 24 horas, durante la cual rsETH no puede entrar ni salir. El equipo declaró que está trabajando con expertos en seguridad en la investigación y enfatizó que la medida es solo a nivel de wallet: los contratos de Kelp permanecen seguros, rsETH sigue totalmente respaldado, y todas las operaciones de minting, retiro e integración continúan con normalidad, sin que se requiera ninguna acción de los usuarios.

We've detected potential suspicious activity on an the address (0xc70f00cd7e461686b04b0e912e309becA8b80ea0) that received rsETH a few hours ago. Out of an abundance of caution, we've placed that address under a temporary 24-hour pause. During this window, rsETH cannot move in…

— Kelp (@KelpDAO) 15 de septiembre de 2026

Abuso a nivel de módulo, no una vulnerabilidad del núcleo de Safe

Los analistas de seguridad subrayaron que se trató de un abuso de autorización de módulo específico de una Safe, no de una vulnerabilidad en los contratos centrales de Safe ni en las claves de los propietarios. Dado que los módulos de Safe se ejecutan con la autoridad de la propia wallet, una falla incluso en una extensión confiable y autorizada puede exponer todo el saldo sin comprometer los controles del propietario. No obstante, el incidente pone de relieve un riesgo persistente para los usuarios de wallets de contratos inteligentes: el núcleo de Safe nunca ha sufrido un exploit directo al protocolo, pero los usuarios han perdido fondos repetidamente debido a infraestructura comprometida y extensiones de terceros vulnerables, incluidos más de $2 millones robados en ataques de envenenamiento de direcciones que afectaron a 21 usuarios de Safe en 2023.

Fuente: Metaverse Post