Comprobar los módulos de tu wallet Safe: cómo un módulo movió 7,7 millones de dólares sin firma

El 15 de septiembre de 2026, una wallet de Ethereum perdió unos 2.882 rsETH sin que hiciera falta ni una sola firma de un propietario. La wallet era una multifirma de Safe, es decir, justo el diseño que pasa por especialmente seguro porque varias claves tienen que firmar juntas. Aun así, el saldo se vació, y lo hizo a través de un módulo que los propios propietarios habían activado. Si usas una wallet de contrato inteligente, la tarea que deja este caso es acotada y concreta: mira qué módulos están activados en tu wallet y elimina todo lo que ya no necesites o ya no sepas explicar.

Este texto explica qué puede hacer técnicamente un módulo, cómo se desarrolló el ataque del 15 de septiembre y cómo realizar tú mismo la comprobación en pocos minutos. El camino por la interfaz no te cuesta ninguna comisión. Solo la eliminación de un módulo es una transacción, y esa sí necesita el número habitual de firmas.

El módulo de Safe explicado: qué puede hacer un módulo en una wallet de contrato inteligente

Un módulo de Safe es un contrato inteligente propio al que la wallet permite de forma permanente ejecutar transacciones en su nombre, sin que se reúna el número habitual de firmas de los propietarios. Eso no es un fallo del diseño, sino la finalidad del diseño. Quien quiere operar un pago de nóminas automático, una rutina recurrente de reequilibrio o una estrategia de liquidez no puede hacer que tres personas firmen cada paso. Así que la wallet delega esa parte en un contrato.

Técnicamente, esto ocurre a través de la función execTransactionFromModule o de su variante con valor de retorno. Un módulo activado la invoca y la wallet ejecuta lo que el módulo le encarga. El umbral de firmas no se elude en el proceso: sencillamente no está previsto para esta vía. La documentación de Safe formula la consecuencia con una claridad poco habitual: los módulos pueden ejecutar transacciones arbitrarias, solo deberían añadirse módulos auditados y de confianza, y un módulo malicioso puede tomar el control completo de una wallet. Se puede leer en la documentación oficial de Safe sobre los módulos de cuentas inteligentes.

Dos propiedades hacen que los módulos resulten atractivos para los atacantes. Primero, son permanentes: una vez activado, un módulo sigue activo hasta que alguien lo desconecta expresamente. Segundo, son invisibles en el día a día. No los ves al enviar, ni al recibir, ni en el saldo. Solo aparecen allí donde uno mira a propósito.

El ataque del 15 de septiembre: cómo DELEGATECALL liberó 2.882 rsETH

La salida de fondos cayó en el bloque 25980525, a las 04:38:47 UTC. Estaba afectada una única wallet de Safe que mantenía una posición apalancada en rsETH, el token de restaking líquido de Kelp DAO. Las firmas de seguridad Blockaid y PeckShield informaron primero del incidente; sus cifras de daños difieren ligeramente y se sitúan entre 7,73 y 7,81 millones de dólares. El dato de cantidad es más preciso que el dato en dólares: 2.882,37 rsETH.

El fallo estaba en un módulo hecho a medida que la wallet empleaba para una estrategia de liquidez en Uniswap v4. Ese módulo ofrecía un punto de entrada que transmitía sin comprobación los datos suministrados por quien llamaba, y lo hacía directamente a la función de la wallet execTransactionFromModuleReturnData con el indicador de operación 1. El indicador 1 corresponde a DELEGATECALL, y ese es el punto decisivo.

DELEGATECALL en una frase

DELEGATECALL ejecuta código ajeno en la memoria y bajo la identidad del propio contrato, como si la wallet hubiera escrito ese código ella misma. Quien puede desencadenar esa llamada no actúa frente a la wallet, sino como la wallet.

Como el punto de entrada del módulo no tenía protección de acceso para quienes llamaban desde fuera, cualquier dirección podía alcanzarlo. Y como el módulo ya estaba activado en la wallet, esta no comprobó nada más. La lista de propietarios y el umbral de firmas dejaron de jugar papel alguno en esta secuencia.

Hook de Uniswap v4 y multicall de keeper: el camino del atacante paso a paso

La cadena tuvo varias fases y utilizó en todo momento funciones pensadas como una comodidad. Primero, el atacante invocó una función pública de multicall de keeper. Los keepers son servicios que mantienen una estrategia en marcha, por ejemplo ajustando posiciones; sus llamadas suelen estar abiertas a propósito, para que cualquiera pueda activarlas y la estrategia nunca se detenga.

Mediante esa llamada dirigió el módulo de liquidez de la wallet hacia un pool de Uniswap v4 que él mismo controlaba. Uniswap v4 permite los llamados hooks, es decir, código propio que se ejecuta automáticamente ante determinados eventos de un pool. El hook de ese pool pertenecía al atacante.

El último paso fue el desempaquetado. La wallet no tenía rsETH desnudo, sino aEthrsETH, es decir, rsETH dentro de la envoltura remunerada del mercado de préstamos Aave. En esa forma no se puede llevar sin más. El hook desempaquetó la tenencia en rsETH libremente transferible, y con ello el saldo quedó móvil.

Un bot MEV en lugar del atacante: por qué "yoink" se llevó el dinero

El atacante envió su transacción al mempool público, es decir, a la sala de espera de transacciones aún sin confirmar que cualquiera puede consultar. Allí leía en paralelo un bot MEV llamado "yoink", que reconstruyó la misma secuencia y llegó primero dentro del mismo bloque. Los 2.882,37 rsETH acabaron en una dirección del bot, con un valor de unos 7,80 millones de dólares según su valoración en el momento de la ejecución.

Para la wallet robada eso no cambia nada. Para ti cambia dos cosas. Primero, el caso demuestra que una vulnerabilidad abierta en un módulo no afecta solo al atacante que la descubre: en cuanto la secuencia es visible públicamente, puede reconstruirla cualquiera que sea lo bastante rápido. Segundo, explica por qué aquí las perspectivas de recuperación son distintas de las de un robo clásico. Kelp DAO puso en pausa la dirección receptora a las 06:03 UTC durante 24 horas y constató al mismo tiempo que sus propios contratos estaban intactos y que el rsETH seguía plenamente respaldado. El fallo estaba en un módulo a medida de una wallet concreta, no en el token ni en el protocolo.

No es el primer caso: el exploit de SquidRouterModule del 25 de mayo de 2026

Quien tome el incidente de septiembre por un caso aislado subestima el patrón. El 25 de mayo de 2026, un ataque alcanzó a un módulo que operaba con el nombre de SquidRouterModule. Según los medios que informaron, se vieron afectadas al menos 86 wallets de Safe en Ethereum y Base; el daño se cifra, según el análisis, en 3,2 millones de dólares o, en otro recuento, en casi 4 millones de dólares repartidos en unas 300 transacciones. El proceso duró alrededor de dos horas.

La vía de ataque fue otra y el resultado, el mismo. En lugar de una entrada por DELEGATECALL, los atacantes emplearon la función executeSameChainActions() y se hicieron pasar por delegados autorizados. Como el módulo ya tenía derechos amplios en las wallets afectadas, los contratos de las wallets trataron las órdenes falsificadas como si fueran auténticas. El proveedor Squid declaró públicamente que el contrato explotado solo compartía el nombre con su propia arquitectura de producto y no guardaba relación con ella, y que sus usuarios e integradores no se habían visto afectados.

De ambos casos se extrae la misma lección. El punto más débil de una multifirma rara vez es hoy el umbral de firmas. Está en los contratos a los que la wallet permitió en algún momento trabajar al margen de ese umbral. Al elegir tu solución de custodia, ese es un criterio que apenas aparece en ninguna descripción de producto; nuestra comparativa de wallets de hardware ordena los dispositivos según cuánto control sobre la firma queda realmente en tus manos.

Comprobar los módulos de Safe: así ves en cinco minutos qué está activado

La comprobación en sí no tiene nada de espectacular, y precisamente por eso se queda tantas veces sin hacer. Hay dos vías, y responden a la misma pregunta.

Por la interfaz: ajustes y lista de módulos

Abre tu wallet en la interfaz de Safe y ve, dentro de los ajustes, al apartado Módulos. Allí figura qué direcciones de contrato están activadas para esa wallet. En la inmensa mayoría de las wallets privadas no hay nada, y ese es el caso bueno. Si hay algo, repasa cada dirección una por una y responde a tres preguntas: ¿recuerdas para qué activaste ese módulo? ¿Sigues usando hoy la aplicación asociada? ¿Y encuentras para esa dirección un proveedor identificable con su informe de auditoría?

Si alguna de esas preguntas queda abierta, el módulo va a la lista de eliminación. Aquí la carga de la prueba recae sobre el lado de conservarlo. Un módulo cuya finalidad ya no sabes nombrar sigue funcionando igualmente.

Por el contrato: getModules e isModuleEnabled

Quien quiera saberlo con independencia de una interfaz pregunta directamente al contrato de la wallet. La función de lectura getModules devuelve las direcciones de todos los módulos activados, e isModuleEnabled responde con un sí o un no, para una dirección concreta, sobre si está activada. Ambas llamadas son de pura lectura: no cuestan comisión, no necesitan firma y se pueden ejecutar desde cualquier explorador de bloques o desde un SDK.

La vía del contrato tiene una ventaja práctica. Te muestra el estado de la cadena y no la representación de una aplicación. Si una interfaz no muestra un módulo por el motivo que sea, aquí aparece igualmente.

Eliminar un módulo: por qué disableModule necesita tu umbral de firmas

La desactivación se hace mediante la función de la wallet disableModule. A diferencia de la consulta, esto sí es una transacción real. Cuesta comisiones de red y necesita el número habitual de firmas de tus propietarios. En la interfaz de Safe inicias el proceso en la misma lista de módulos que acabas de consultar; después los propietarios confirman como en cualquier otra transacción.

Conviene que conozcas una particularidad: los módulos están guardados en el contrato como una lista enlazada, de modo que la desactivación necesita también la dirección de la entrada anterior. Las interfaces y los SDK introducen ese valor por sí mismos. Quien construya la transacción a mano tiene que averiguarlo, o la llamada fallará.

Planifica la eliminación para un momento con comisiones de red bajas y despacha varios módulos en una misma sesión. Para la simple consulta eso no rige: no cuesta nada y puede hacerse de inmediato.

Aprobaciones de tokens y módulos: dos permisos, dos comprobaciones separadas

Aquí surge con regularidad una confusión que puede salir cara. Una aprobación de tokens, approve en la jerga de los contratos, permite a un contrato ajeno cargar una cantidad determinada de un token determinado desde tu dirección. Un módulo, en cambio, permite a un contrato ajeno actuar dentro de tu wallet, y hacerlo sobre todas tus tenencias.

La diferencia de alcance es considerable, y por eso ninguna de las dos comprobaciones sustituye a la otra. Quien haya revocado limpiamente sus aprobaciones puede tener aun así un módulo activo con acceso completo. Cómo despejar las aprobaciones y cuánto cuesta una revocación al precio del gas actual lo hemos descrito en nuestra guía sobre las aprobaciones de tokens en Ethereum. Para los módulos se aplica además la comprobación del apartado anterior.

Por lo demás, ambas comprobaciones solo afectan a las wallets que gestionas tú mismo. Si tu saldo está en un exchange, decide su custodia, y allí la lista de comprobación es completamente distinta.

Envoltorios de restaking como aEthrsETH: por qué los tokens empaquetados agrandan el daño

Un aspecto secundario del caso merece atención propia. La wallet afectada mantenía su Ethereum en forma empaquetada varias veces: primero como token de restaking líquido rsETH y después una vez más como aEthrsETH remunerado en el mercado de préstamos. Cada envoltorio es un contrato más que trae consigo derechos, reglas y, en caso de duda, también sus propias vulnerabilidades.

Para ti eso significa sobre todo una cosa: cuanto más profundo es el empaquetado, más larga es la cadena de contratos que tendrías que revisar para entender de verdad tu posición. Quien construya rendimiento mediante restaking y préstamos debería al menos saber nombrar las capas implicadas. Nuestro repaso de las plataformas de staking indica para cada proveedor cuántas capas de contratos hay entre tú y tu ether.

Para ser completos: Kelp DAO declaró expresamente el 15 de septiembre que sus propios contratos no estaban afectados y que el rsETH sigue respaldado. El empaquetado no causó el daño. Lo hizo móvil en cuanto el atacante tuvo acceso a la wallet.

Obligación de notificación desde el 11 de septiembre: qué cambia el Cyber Resilience Act para los proveedores de wallets

Para ti como usuaria o usuario en Alemania se añade una novedad regulatoria que cambia el tratamiento de este tipo de brechas. Desde el 11 de septiembre de 2026 rigen las primeras obligaciones de notificación del Cyber Resilience Act de la UE. Los fabricantes de productos con elementos digitales deben notificar una vulnerabilidad explotada activamente en un plazo de 24 horas desde que tienen conocimiento de ella, como aviso previo, a la agencia europea ENISA y al equipo nacional competente de respuesta a incidentes informáticos; la notificación detallada de la vulnerabilidad sigue como muy tarde a las 72 horas. La obligación alcanza también a productos que ya están en el mercado.

El software de wallets entra dentro, y hemos analizado con más detalle las consecuencias para los proveedores en nuestro artículo sobre la obligación de notificación para fabricantes de monederos. En la práctica significa: con un proveedor con sede o distribución en la UE deberías enterarte en adelante con rapidez de una brecha explotada activamente.

Esta protección tiene, eso sí, un límite, y el caso del 15 de septiembre lo muestra con claridad. El módulo defectuoso no era el producto de un fabricante, sino un contrato hecho a medida para una única wallet. Para contratos construidos por uno mismo o encargados de forma individual no hay nadie que te avise. Ahí la comprobación sigue siendo tarea tuya.

Comprobar los módulos de Safe: lo que debes llevarte

1. Mira hoy tu lista de módulos. Abre los ajustes de tu wallet de contrato inteligente y lee las direcciones de contrato activadas. No cuesta comisión ni firma. Si de todos modos estás pensando en tu custodia, compara en paralelo qué solución encaja con tus tenencias: los dispositivos están uno al lado del otro en nuestra comparativa de wallets de hardware.
2. Elimina lo que ya no sepas explicar. Todo módulo cuya finalidad no puedas nombrar o cuya aplicación ya no uses debe desconectarse mediante disableModule. Planifica la transacción para un momento de comisiones bajas. Quien prefiera guardar sus tenencias diarias en una wallet ligera sin lógica de módulos encontrará a los candidatos en nuestra comparativa de wallets de software.
3. Cuenta las capas de tu posición de rendimiento. Anota para cada posición empaquetada qué contratos hay entre tú y tu ether, y decide si el rendimiento adicional te compensa esa cadena. Los proveedores y sus capas de contratos están en nuestro repaso de las plataformas de staking.

El caso del 15 de septiembre no es un argumento contra las wallets de contrato inteligente. Es un argumento a favor de leer la única lista que nadie lee. Los detalles del proceso los reconstruyó The Crypto Times el 15 de septiembre.

(16 de septiembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)