FlashLoopAdapter flaw let attacker drain $305K from Aave-linked Safe wallets

A third-party adapter, not Aave, was the weak point

On October 1, 2026, an attacker siphoned roughly $305,000 to $310,000 in collateral from two Safe wallets, both controlled by the same owner, according to a technical write-up published on dev.to. The wallets had enabled a custom module called FlashLoopAdapter, built to automate opening and closing leveraged positions on Aave V3. The core Aave protocol was never compromised. Aave founder Stani Kulechov told the community the exploited code was a third-party external adapter with "zero effect on Aave v3."

Defimon Alerts first flagged the unusual activity at 15:08:57 UTC that day, and SlowMist later published an independent analysis confirming the exploit. Early on-chain numbers exaggerated the damage: Etherscan showed a gross transaction value of about $3.88 million, but that only measured the total collateral moved through the attack transaction. Once the attacker repaid the flash loan and settled the associated debts, Defimon Alerts pegged the net loss at roughly $305,000, while SlowMist estimated around $310,000.

How the attack was sequenced

The attacker needed none of their own capital. Per the dev.to breakdown, the sequence ran as follows: the attacker took a WETH flash loan from Morpho, used it to repay roughly 1,335 WETH of Aave-backed debt held by the first victim Safe, and that repayment unlocked the collateral behind the leveraged position. With the position freed, the attacker withdrew about 1,306.48 weETH from the wallet. The same vulnerable code path was then used against a second Safe tied to the adapter, pulling out an additional 6.4 weETH. After repaying the Morpho loan and converting part of the haul, the attacker walked away with a net profit of approximately 114.09 ETH.

The authentication bypass at the center

The bug lived in the adapter's access-control logic, specifically in its open() and close() functions. These were supposed to confirm that whoever triggered them was a genuine Safe wallet that had explicitly enabled the module. Instead of proving anything, the check simply asked the caller, and the attacker deployed a fake Safe contract that answered affirmatively when queried.

That got the attacker past the front gate, but a second weakness turned a spoofing bug into a full drain. The adapter's internal _swap() function let the caller supply arbitrary transaction data and choose the swap router. The attacker pointed the router at the victim's own Safe and crafted calldata invoking execTransactionFromModule. Because FlashLoopAdapter was already an authorized module on that Safe, the wallet executed the call without question, in effect draining its own funds.

Part of a wider pattern

The write-up situates the incident in a broader trend around Safe module permissions. In a separate September case, a Safe holding a leveraged Aave V3 position lost roughly 2,900 rsETH after weak authorization checks in an executor contract attached to an enabled module. The attack paths differed, but both incidents trace back to the same structural risk: execution rights delegated to peripheral contracts.

Why it matters

Safe modules exist to remove friction; once enabled, they can act on a wallet without a signature for every operation. That autonomy is what makes leveraged looping convenient, and it is also what converted a narrow caller-spoofing flaw into unrestricted access to wallet collateral. The dev.to analysis draws out three lessons: authentication must go beyond a contract's self-reported identity, using bytecode verification or cryptographic signatures; functions that accept arbitrary calldata and arbitrary routers should be constrained to predefined, audited paths; and users should treat enabling a module as granting meaningful autonomy, checking its access scope and audit history before switching it on. Analysts at ChainSentinel, cited in the write-up, argue that peripheral integrations routinely introduce the most serious vulnerabilities in complex DeFi stacks. As composability deepens, the attack surface is migrating from core lending pools toward the adapters, wrappers and modules built around them, and this incident is a clean illustration of that shift.