El punto ciego de las wallets modulares: permisos que nadie vuelve a revisar

El 15 de septiembre un atacante drenó cerca de 2.900 rsETH —unos USD 7,7 millones— de una wallet Safe en Ethereum, sin que ninguno de sus propietarios firmara una sola transacción.

La firma de seguridad Blockaid detectó el incidente en tiempo real. Antes de que el atacante pudiera moverlos, un bot MEV conocido como Yoink ejecutó una transacción propia en el mismo bloque y se quedó con los fondos.

El caso invita a una lectura que va más allá del monto robado. La pregunta relevante no es cómo entró el atacante, sino por qué una wallet diseñada para exigir múltiples firmas terminó ejecutando una operación que ningún propietario aprobó. La respuesta obliga a repensar qué significa realmente estar seguro.

Una wallet Safe multifirma exige, por diseño, que un número mínimo de propietarios apruebe cada operación. Pero Safe permite agregar «módulos»: contratos externos a los que se les otorga permiso permanente para ejecutar ciertas acciones, sin pasar por ese proceso de firma cada vez. Es equivalente a entregarle a un proveedor de confianza una llave que abre una puerta específica de la casa de forma indefinida, para no tener que abrirle personalmente cada visita.

En este caso, la wallet tenía habilitado un módulo de contrato inteligente —un contrato «Multicall»— para gestionar posiciones de liquidez en Uniswap v4. Ese contrato tenía un error de verificación de autorización: trataba como legítima cualquier llamada que apuntara de vuelta a su propia dirección.

Esa falla fue justamente la que convirtió un componente de confianza en una puerta abierta.

Aprovechando ese defecto, el atacante utilizó un «multicall» público —una función que agrupa varias operaciones en una sola transacción, diseñada originalmente para automatizar tareas rutinarias— . De esta forma pudo redirigir el módulo hacia un fondo de liquidez creado por él mismo. Ahí, el contrato desenvolvió los activos de rendimiento aEthrsETH de la wallet y los convirtió en rsETH ordinario, dejando a la víctima con un certificado de posición sin valor.

El módulo, no las claves, fue el verdadero perímetro

El mecanismo que operó en este caso desplaza el eje de la discusión sobre seguridad. En una wallet tradicional, comprometer los fondos exige robar o forzar claves privadas. Pero, en una wallet modular como Safe, basta con que uno solo de los módulos autorizados en el pasado tenga una falla. Esto, sin importar cuántas firmas se requieran para el resto de las operaciones.

El problema de fondo es que estos permisos rara vez se revisan después de otorgados. Un módulo se instala para resolver una necesidad puntual (como gestionar una posición de DeFi, automatizar una estrategia) y queda activo indefinidamente, acumulándose junto a otros permisos similares. Cada uno amplía la superficie de ataque sin que el propietario vuelva a evaluarlo.

No se trata entonces de un incidente aislado. Un caso similar ocurrió en mayo de 2026, cuando un módulo llamado SquidRouterModule permitió drenar cerca de USD 3,2 millones de 86 Safes distintos por el mismo tipo de falla: verificación de origen insuficiente en un componente externo autorizado, según reportó CriptoNoticias.

La repetición del patrón sugiere que no se trata de un error puntual de programación, sino de un punto ciego estructural en cómo se diseñan y auditan los módulos de wallets inteligentes.

Un bot ganó la carrera que la wallet ya había perdido

El desenlace añadió una segunda capa al caso. Como la transacción del atacante quedó expuesta en el mempool público —el espacio donde las operaciones esperan a ser incluidas en un bloque antes de confirmarse—, el bot Yoink la detectó y pagó cerca de USD 46.000 en prioridad a quien construyó el bloque para que su propia transacción se ejecutara primero. Ambos intentos terminaron en el mismo bloque, pero Yoink llegó antes.

Kelp DAO, el protocolo detrás de rsETH, colocó la dirección receptora bajo una pausa preventiva de 24 horas y aclaró que sus contratos permanecen intactos. Ni el propietario original ni el atacante controlaron el destino final de los fondos.

Este segundo episodio no resuelve el problema de fondo, solo lo desplaza. Que un tercer actor, más veloz en la carrera del mempool, haya capturado los activos en lugar del atacante no es una forma de seguridad; es una casualidad de mercado. La wallet perdió el control de sus fondos en el mismo instante en que el módulo ejecutó una operación no autorizada, sin importar quién terminara quedándoselos.

El caso deja una lección que trasciende este incidente puntual: en una wallet modular, la autocustodia real no depende solo de quién posee las claves privadas, sino de qué contratos externos tienen, en la práctica, capacidad de actuar en su nombre. Cada módulo habilitado y olvidado es, en los hechos, una firma permanente que el propietario ya dio sin saberlo.