Un módulo personalizado de Ethereum construido para gestionar posiciones apalancadas en Aave V3 fue explotado el 1 de octubre de 2026, drenando más de $300.000 de dos carteras Safe en lo que los investigadores de seguridad ahora están llamando uno de los casos de explotación de Aave V3 más técnicamente precisos del año. La brecha no tocó en absoluto los contratos de préstamos principales de Aave. En cambio, los atacantes encontraron una fisura en un complemento de terceros llamado FlashLoopAdapter, un módulo diseñado para abrir y cerrar posiciones apalancadas de Aave para usuarios de carteras Safe.
Puntos clave
FlashLoopAdapter, un módulo personalizado de Ethereum para posiciones aprovechadas de Aave V3, fue explotado el 1 de octubre de 2026.
Más de $300,000 se drenaron de dos carteras Safe, y las firmas de seguridad Defimon Alerts y SlowMist estimaron pérdidas entre $305,000 y $310,000.
El atacante reembolsó aproximadamente 1,335 WETH en deuda de Aave y luego retiró alrededor de 1,306.48 weETH de una cartera y 6.4 weETH de una segunda.
Se usó un préstamo flash de WETH de Morpho para llevar a cabo el ataque, y el atacante mantuvo aproximadamente 114 ETH después.
La vulnerabilidad fue un fallo de control de acceso en el propio FlashLoopAdapter, no en el protocolo subyacente de préstamos de Aave.
El exploit de FlashLoopAdapter drena más de $300,000 de carteras Safe
El incidente se desarrolló el 1 de octubre, cuando un contrato controlado por el atacante logró colarse por los controles de acceso incorporados en FlashLoopAdapter. La firma Defimon Alerts marcó la actividad en X, describiendo cómo la ruta de ejecución del módulo permitió al atacante interactuar directamente con dos carteras Safe que tenían el adaptador habilitado para posiciones apalancadas en Aave.
Detalles del Exploit del 1 de octubre de 2026
Una vez dentro, el atacante no necesitó tocar el fondo principal de préstamos de Aave. Simplemente usó los permisos propios de FlashLoopAdapter para mover el colateral fuera de las carteras que se suponía que debía gestionar de forma segura. Esa distinción es importante: esto no fue una brecha del propio Aave, sino de una capa construida sobre él.
Montos drenados y activos robados
En la primera cartera, el atacante reembolsó aproximadamente 1,335 WETH de la deuda de Aave pendiente, un paso que desbloqueó el colateral detrás de ella. Luego retiró alrededor de 1,306.48 weETH de esa misma cartera Safe. Una segunda cartera vinculada al mismo módulo perdió una cantidad menor, aproximadamente 6.4 weETH, en la misma secuencia de transacciones.
Tras el retiro, el atacante convirtió una parte de los activos robados y terminó con aproximadamente 114.1 ETH, según el seguimiento de Defimon. Un registro en Etherscan vinculado a la primera cartera mostró la quema de unos 1,306.48 tokens variableDebtEthWETH junto con un retiro weETH correspondiente. Etherscan listó el valor bruto de la transacción en alrededor de $3.88 millones, pero esa cifra refleja el total de colateral movido a través de la transacción, no la ganancia real del atacante. La estimación de Defimon de $305,000 y la cifra cercana de SlowMist, de aproximadamente $310,000, reflejan mejor el daño financiero real una vez que se consideran el préstamo flash y el pago de la deuda.
Causa técnica: Fallo de control de acceso en el módulo FlashLoopAdapter
La causa raíz se remonta a cómo FlashLoopAdapter verificaba quién estaba autorizado para activar sus funciones. Un contrato controlado por el atacante pasó esas verificaciones cuando no debería, abriendo la puerta a toda la secuencia que siguió.
Papel de la vulnerabilidad de control de acceso
Esta es la parte de la historia que separa un ataque a FlashLoopAdapter de un fallo genuino del protocolo de Aave. La documentación de Aave enumera el préstamo, el reembolso, los retiros y los préstamos flash como funciones estándar del pool de préstamos V3, y aquí no se rompió ninguna de esas funciones principales. La debilidad vivía por completo dentro del contrato adaptador personalizado al que los usuarios de carteras Safe habían optado para gestionar su exposición apalancada. SlowMist, que revisó el incidente de forma independiente, informó que el atacante usó una cartera Safe falsificada para superar la autenticación y luego confió en datos arbitrarios de transacción para llegar a los fondos.
Uso de un préstamo flash de WETH de Morpho
Los préstamos flash son una herramienta rutinaria en las finanzas descentralizadas: un contrato toma fondos prestados para una sola transacción y debe devolverlos, además de una comisión, antes de que esa transacción finalice. Como parte de la secuencia del ataque, el atacante tomó un préstamo de WETH de Morpho, confiando en ese capital prestado para llevar a cabo los pasos de reembolso de la deuda y el retiro sin comprometer ninguno de sus propios fondos. El uso de un préstamo flash por sí solo no es evidencia de mala conducta por parte del prestamista; Morpho simplemente proporcionó un servicio estándar y sin permisos que el atacante incorporó en un exploit más amplio construido alrededor de la brecha de control de acceso de FlashLoopAdapter.
Estado de la investigación y contexto de seguridad más amplio
La investigación sobre FlashLoopAdapter sigue abierta y aún no se ha confirmado si otras carteras o contratos vinculados al módulo se vieron afectados más allá de los dos reportados hasta ahora. Esa incertidumbre vale la pena considerarla: una vulnerabilidad en una cartera Safe como esta no necesariamente se mantiene contenida automáticamente en las direcciones ya identificadas, especialmente cuando el fallo está en infraestructura compartida y no en la configuración de un solo usuario.
Investigación en curso e impacto incierto
Por qué esto importa para el mercado más amplio de apalancamiento en DeFi es sencillo. Las carteras Safe combinadas con módulos personalizados se han convertido en una forma común de gestionar posiciones apalancadas entre distintos protocolos de préstamos, y este incidente muestra que la seguridad del protocolo subyacente no garantiza la seguridad de todo lo construido a su alrededor. Los contratos principales de Aave resistieron bien durante el episodio, pero eso ofreció poca tranquilidad a las dos carteras cuyo colateral se drenó a través de un módulo que la mayoría de los usuarios probablemente asumía que era solo una capa de conveniencia.
Comparación con exploits previos de carteras Safe
No es la primera vez este año que se ataca una posición apalancada de Aave V3 vinculada a una cartera Safe. Una cartera Safe diferente, que mantenía una posición apalancada en Aave V3, perdió alrededor de 2,900 rsETH el 15 de septiembre, una cantidad que valía aproximadamente $7.8 millones en ese momento. En ese incidente, se usó un hook de Uniswap V4 para convertir la posición en rsETH transferible, pero un bot llamado Yoink logró adelantarse (front-run) a la propia transacción del atacante y reclamar los fondos. Kelp DAO, el protocolo detrás de rsETH, pausó posteriormente la dirección receptora y dijo que sus contratos principales y el respaldo de rsETH permanecieron sin verse afectados.
Juntas, las dos incidencias apuntan a un patrón recurrente en lugar de un accidente aislado: las herramientas superpuestas sobre Aave V3 para facilitar la gestión del apalancamiento siguen convirtiéndose en el eslabón más débil, incluso cuando el protocolo base de Aave permanece intacto. Para cualquiera que ejecute posiciones apalancadas mediante un módulo de cartera Safe, esa distinción merece recordarse la próxima vez que un titular mencione un exploit de Aave V3: el protocolo en sí puede estar bien, pero el andamiaje alrededor de él es donde el riesgo tiende a aparecer.
Artículo producido con la asistencia de inteligencia artificial y revisado por el equipo editorial.