Safe nuevamente bajo ataque pierde 305.000 dólares en criptoactivos

Dos carteras multifirma Safe perdieron su colateral en una sola transacción de Ethereum. En el bloque 26.098.264, a las 15:08 UTC del 1 de octubre de 2026, un atacante se llevó de ambas 114,09 ETH, unos 305.000 dólares según el análisis de Verichains que reconstruyó el caso paso a paso.

El agujero estaba en FlashLoopAdapter, un módulo de terceros que abría y cerraba posiciones apalancadas en Aave v3. Conviene entender qué es un módulo antes de seguir, porque ahí está todo el asunto. Un módulo de Safe es un contrato que los dueños autorizan a mover fondos y ejecutar transacciones en nombre de la cartera, sin pedir firmas en cada operación. Ese permiso pesa lo mismo que el de un firmante, y la propia documentación de Safe avisa desde hace años de que solo deben activarse módulos auditados.

FlashLoopAdapter no tenía auditoría publicada ni revisión externa conocida. Su único control de acceso consistía en preguntarle al propio llamador si estaba autorizado, un método que cualquiera puede falsear respondiendo que sí. El módulo aceptó la palabra de un contrato falso, le dejó elegir el destino y los datos de la llamada, y terminó ejecutando órdenes contra las dos carteras que sí confiaban en él. Ni Aave ni los contratos centrales de Safe fallaron, y ese detalle es lo incómodo para quien automatice una multifirma con código ajeno.

Lo qué ocurrió dentro de un solo bloque

Todo el ataque cabe en la transacción 0x75328f91, incluida en el bloque 26.098.264 a las 15:08:47 UTC del 1 de octubre de 2026. El atacante pidió prestados 11.537,24 WETH a Morpho Blue en un préstamo flash, dinero que se recibe y se devuelve dentro de la misma operación. Pidió nueve veces más de lo que necesitaba y devolvió el sobrante.

Con ese dinero pagó la deuda de la cartera grande en Aave. El evento Repay del pool registra 1.335,255803 WETH, identifica a la Safe como prestataria y al contrato del atacante como pagador. Saldar la deuda era obligatorio, porque Aave no libera colateral que respalda un préstamo vivo, y esa cartera tenía 1.306,48 weETH inmovilizados por una deuda variable de 1.335,26 WETH.

Con la deuda a cero, el atacante usó el módulo para que la cartera grande le entregara sus 1.306,48 weETH. Repitió la jugada con una segunda cartera del mismo dueño, que transfirió 6,43 weETH. Después cambió los 1.312,90 weETH resultantes por 1.449,3520 WETH a través de Curve, Fluid y Uniswap, con el agregador AugustusV6 de Velora.

El préstamo de Morpho se devolvió íntegro y el sobrante acabó convertido en ETH. El saldo que llegó a la dirección del atacante fue de 114,096151 ETH, la cifra sobre la que se sostiene todo el cálculo de la pérdida neta.

¿Por qué el módulo confiaba en quien lo llamaba?

El fallo tuvo dos mitades que encajaron después como una sola herramienta de saqueo. La primera estaba en el control de acceso de las funciones open() y close(), que comprobaban si el llamador era una Safe con el módulo activado. Para averiguarlo, el módulo ejecutaba isModuleEnabled sobre el propio llamador, o sea, preguntaba al sospechoso si él mismo estaba autorizado.

Una Safe real responde con honestidad a esa consulta, pero cualquier contrato puede escribir la misma función y devolver siempre verdadero. El módulo no comprobaba nada por su cuenta, aceptaba la respuesta del llamador y seguía adelante. Es el error de autorización más viejo del libro, y aquí costó colateral real.

La segunda mitad estaba en el tramo de intercambio. Todos los parámetros los aportaba quien llamaba: el proveedor del préstamo flash, el router de swaps y los datos que se enviarían a ese router. El módulo aprobaba al router para gastar el token de entrada y después reenviaba la llamada con el destino y el contenido recibidos.

Una guarda que no funcionaba

La guarda del callback solo verificaba que la respuesta viniera del proveedor declarado y que los parámetros cuadraran con el hash comprometido al inicio. El atacante se puso a sí mismo como proveedor y cumplió las dos condiciones sin despeinarse.

Con esas dos piezas, el resto fue mecánico. El atacante puso como router a una de las carteras víctimas y como datos de la llamada una orden execTransactionFromModule, la función que un módulo usa para pedir a la Safe que ejecute algo. La cartera vio que le hablaba su propio módulo habilitado.

Esa es la clave del caso. En la ruta de los módulos, la Safe no verifica firmas de los dueños, sino que ejecuta lo que le pide el contrato que ella misma autorizó, sin preguntar quién está detrás de esa petición. Con dos retiradas de weETH, el colateral salió de las dos carteras.

Los detalles de contexto rematan el diagnóstico. El contrato se desplegó el 16 de julio de 2026 y las dos carteras lo activaron al día siguiente, según Verichains. Ninguna otra Safe aparece en su historial de transacciones, lo que apunta a herramienta privada y no a un producto público con muchos usuarios.

Los números del incidente

Los números del incidente son claros y transparentes gracias a blockchain:

La última fila merece una advertencia de lectura. Los 114,09 ETH son el beneficio neto después de devolver el préstamo flash y cubrir la deuda de Aave, no el valor del colateral que se movió. Quien sume los 1.306 weETH a la pérdida contará dos veces el mismo dinero, porque esa cantidad salió del pool para pagar el préstamo temporal.

Ni Aave ni Safe tienen un fallo que corregir

Stani Kulechov, fundador de Aave, salió a acotar el alcance del incidente: el contrato explotado era un adaptador externo construido encima de Aave y no afectaba a Aave v3. La versión encaja con la evidencia onchain, porque el pool prestó, cobró y liberó colateral siguiendo sus reglas sin ninguna irregularidad en su lógica.

En el lado de Safe ocurre lo mismo, y con un matiz que conviene subrayar. La documentación del proyecto clasifica los módulos como elemento de riesgo crítico y recomienda añadir solo código auditado, porque un módulo malicioso puede hacerse con el control de la cartera. El centro de ayuda es aún más explícito sobre su catálogo, ya que fuera de los límites de gasto no mantiene ningún módulo oficial.

Safe no ha publicado un comunicado específico sobre FlashLoopAdapter. Lo que sí ha movido en el mismo periodo son dos piezas que apuntan al problema de fondo. El 22 de septiembre de 2026, nueve días antes del incidente, Safe{Wallet} estrenó la versión 1.5.0 de sus contratos con el Module Guard, un mecanismo que revisa cada transacción de módulo con las mismas reglas que las demás. Y el 15 de octubre, la Fundación Safe lanzó Safenet Aegis, una red de verificación de transacciones cuyo reglamento incluye entre los casos que debe marcar los cambios no autorizados en dueños y módulos de una Safe.

Un patrón que ya se había cobrado millones

Otra Safe perdió 2.900 rsETH, unos 7,8 millones de dólares, el 15 de septiembre de 2026, dieciséis días antes de este exploit. El atacante aprovechó una comprobación mal escrita en el router que se escondía detrás de un módulo habilitado. Esa comprobación devolvía verdadero siempre que el destino de la llamada fuera el propio router, lo que bastaba para colar una orden anidada y ejecutar código en el contexto de la cartera. La operación acabó en manos de un bot de MEV llamado Yoink, que se adelantó al atacante en el mismo bloque.

Cuatro meses antes, el módulo SquidRouterModule vació unas 86 carteras Safe en Ethereum y Base y se llevó alrededor de 3,2 millones de dólares en dos horas. El detalle más llamativo es que la autorización consistía en una cadena de texto constante y pública escrita en el propio contrato verificado, así que cualquiera podía copiarla, presentarla y ejecutar lo que quisiera. Squid tuvo que aclarar que no había construido ni desplegado ese contrato, y el CEO de Safe Labs apuntó entonces que las carteras afectadas no parecían operadas desde el producto oficial de Safe.

Los tres casos comparten la misma estructura. La firma múltiple funciona, los contratos centrales funcionan y el dinero se va por una extensión que los dueños instalaron para ahorrarse trabajo manual. La diferencia entre un módulo y un firmante es que el firmante tiene que aprobar cada operación, mientras que el módulo recibe un permiso permanente y lo ejerce cuando quiere.

El 10% que nadie cobró

El dueño de las dos carteras intentó negociar. El 1 de octubre a las 21:03 UTC, la dirección con el nombre ENS aavechan.eth envió un mensaje onchain al atacante con una oferta habitual en estos casos: quedarse con 11,41 ETH en concepto de recompensa, el 10% del botín, y devolver 102,69 ETH antes del 3 de octubre a las 18:00 UTC. Si el dinero volvía, el asunto se cerraba como rescate de sombrero blanco.

La oferta no tuvo respuesta conocida, y hasta el 16 de octubre ninguna fuente registra una devolución. El dinero salió de la dirección del atacante en las horas siguientes al golpe. El caso sigue abierto en la contabilidad de DeFiLlama con la etiqueta de control de acceso indebido y una estimación de 305.000 dólares, la misma cifra que manejan Verichains y SlowMist.

Revisa si tu Safe tiene módulos activados

El daño se puede auditar antes de que ocurra, y las comprobaciones no requieren conocimientos de Solidity. Estas son las que la documentación de Safe y los análisis posteriores señalan como prioritarias.

• Enumera los módulos habilitados con getModulesPaginated y confirma que reconoces el autor de cada uno. No basta con getModules, que devuelve como máximo diez entradas.
• Desactiva cualquier módulo cuyo autor y revisor no puedas identificar. Un módulo que ya no usas conserva el permiso de ejecución hasta que lo quitas.
• Trata cada módulo como si fuera un firmante más. Si no dejarías que una persona moviera la tesorería sin revisarla, tampoco se lo permitas a un contrato sin leerlo antes.
• Desconfía de los módulos que aceptan el router de swaps y los datos de la llamada desde fuera. Deberían traer una lista de routers permitidos que excluya a las propias carteras Safe.
• Comprueba de dónde sale la autorización. Si la respuesta sobre si el llamador está autorizado viene del llamador, no hay autorización real, solo una cortesía falsificable.
• Actualiza a la versión 1.5.0 o superior si sigues en 1.3.0 o 1.4.1. El Module Guard añade una revisión de cada transacción de módulo que antes no existía.

Una multifirma vale lo que vale el permiso que delegas

Safe tiene razón en su defensa, porque su contrato central no falló y la arquitectura de módulos es una decisión deliberada de diseño, pensada para que equipos y protocolos automaticen operaciones sin renunciar a la firma múltiple. El problema es que esa flexibilidad traslada el riesgo a un punto que casi nadie revisa, ya que instalar un módulo se parece más a marcar una casilla en una interfaz que a conceder un poder permanente sobre el patrimonio.

El patrón de 2026 lo deja claro. De un lado está la multifirma y del otro todas las extensiones que actúan en su nombre, y el atacante elige siempre la más débil. La industria ha aprendido a endurecer los protocolos centrales y a vigilar las firmas, pero FlashLoopAdapter demuestra que el hueco se ha mudado a los permisos que se conceden una vez y se olvidan para siempre. Una cartera Safe con un módulo sin auditar no es una multifirma con un extra útil, sino una multifirma con un firmante anónimo.