Así vaciaron $3.2M de billeteras Safe en Ethereum y Base

Una vulnerabilidad vinculada a un módulo de billetera Safe de terceros provocó el robo de aproximadamente $3.2M en Ethereum y Base, después de que los atacantes explotaran permisos de ejecución delegada para vaciar docenas de cuentas inteligentes en aproximadamente dos horas.

La firma de seguridad blockchain Blockaid indicó que el exploit apuntó a un contrato identificado como SquidRouterModule, afectando al menos a 86 billeteras Gnosis Safe, antes de que los activos robados se convirtieran en Dai a través de pools de Uniswap V3 controlados por los atacantes.

Los datos compartidos por la firma mostraron que el atacante luego consolidó las ganancias en una billetera que contenía aproximadamente 3.07 millones de DAI.

Registros on-chain vinculados por Blockaid identificaron la dirección del explotador como 0x9bdc730183821b6bb2b51be30b77c964fa645b91. 

Datos de Etherscan citados por Lookonchain mostraron que la dirección había sido financiada a través de Tornado Cash y registró 52 transacciones el 25 de mayo.

La misma investigación también rastreó una transacción de vaciado de ejemplo ejecutada a las 06:25 UTC, en la que los activos robados, incluidos USDC, ENA y USDT, se canalizaron a través de pools de liquidez de Uniswap V3 antes de la conversión.

¿Cómo se ejecutó el exploit?

Los hallazgos iniciales de Blockaid sugirieron que la explotación se originó por un fallo en la función executeSameChainActions() del módulo de terceros y no en la infraestructura central de Safe. 

Según la firma, el atacante desplegó contratos de exploit basados en Foundry que abusaron de la ruta de ejecución DelegateBundler del módulo para hacerse pasar por delegados autorizados vinculados a las billeteras víctimas.

Una vez eludadas las comprobaciones de verificación, el atacante pudo iniciar intercambios arbitrarios directamente desde los Safes afectados sin necesitar las aprobaciones multisig normales exigidas por el sistema de billeteras. 

Blockaid dijo que el exploit permitió al atacante intercambiar activos legítimos por un token inútil creado por el atacante identificado como “u”, antes de que se retirara la liquidez y las ganancias se convirtieran en DAI.

Sospecha de suplantación de delegados en la explotación del módulo

Un análisis técnico adicional compartido por Cos, fundador de SlowMist, sugirió que el problema no estaba relacionado con claves privadas comprometidas. 

En una publicación traducida en X, Cos dijo que las billeteras víctimas muestreadas estaban mayormente configuradas como Safes de firma única pertenecientes a distintos usuarios, mientras que la verdadera debilidad parecía provenir de módulos de billetera vulnerables adjuntos a esas cuentas.

Según Cos, los atacantes pudieron falsificar mensajes y eludir las comprobaciones de verificación del módulo, lo que permitió operaciones no autorizadas de canje y transferencia desde las billeteras Safe afectadas. 

El investigador también señaló la misma billetera de consolidación identificada por Blockaid, donde supuestamente se asentaron los fondos robados.

Billetera del atacante con DAI. Fuente: Etherscan.

El exploit básicamente se basó en cómo operan los módulos Safe dentro de las billeteras con contratos inteligentes. 

A diferencia de las transacciones estándar de Safe que requieren aprobaciones de varios propietarios, los módulos pueden ejecutar acciones directamente una vez que los usuarios les conceden permisos de confianza. 

El fallo dentro de SquidRouterModule pareció derivar de una validación de identidad inadecuada, lo que supuestamente permitió que cargas maliciosas se hicieran pasar por delegados aprobados.

Dado que el módulo ya poseía amplios permisos de ejecución dentro de las billeteras conectadas, las solicitudes forjadas fueron aparentemente tratadas como instrucciones legítimas por los propios contratos Safe.

Billeteras afectadas no vinculadas a Safe

El CEO de Safe Labs, Rahul Rumalla, dijo más tarde que las cuentas comprometidas “no parecen operar en el producto oficial Safe Wallet”, y añadió que los investigadores aún no saben dónde se crearon y gestionaron originalmente las billeteras.

Rumalla afirmó que las billeteras afectadas probablemente se desplegaron mediante integraciones externas en lugar de a través de la interfaz oficial de Safe.

Rumalla también dijo que Safe Shield, el sistema de alerta integrado de la compañía impulsado por Blockaid, ya había identificado el módulo como malicioso antes del incidente.

Según él, el sistema de protección alerta a los usuarios cuando módulos o guards no verificados solicitan permisos peligrosos.

Squid niega su implicación

Mientras tanto, Squid negó que su propia infraestructura de enrutamiento o contratos principales hubieran sido vulnerados. 

En un comunicado publicado en X, el equipo dijo que el contrato explotado simplemente compartía el nombre SquidRouterModule y no tenía conexión con la arquitectura del router de producción de Squid.

El protocolo añadió que todos los usuarios e integradores de Squid permanecieron sin verse afectados, describiendo el incidente como un exploit de un módulo de billetera inteligente de terceros no relacionado con los contratos o servicios oficiales de Squid.

El ataque se ha sumado a una lista creciente de incidentes de seguridad DeFi reportados en 2026. 

Como informó previamente Invezz, la semana pasada Echo Protocol sufrió un exploit en Monad después de que los atacantes acuñaran aproximadamente $76.7 million en tokens eBTC no autorizados, lo que los investigadores más tarde relacionaron con un compromiso de clave administrativa. 

Los investigadores en ese caso también dijeron que la blockchain en sí no fue vulnerada, mientras que controles operativos débiles en torno a permisos delegados y autoridad de acuñación permitieron que el exploit escalara.