An attacker drained approximately 114.09 ETH, worth about $305,000, from two Safe multisig wallets after exploiting a third-party module designed to manage leveraged Aave v3 positions, according to a new forensic analysis from SlowMist.
The vulnerability was not in Aave v3 itself, and current evidence does not point to a flaw in Safe’s underlying multisignature contracts. Instead, the attack targeted FlashLoopAdapter, an external module that affected Safes had deliberately enabled to automate leveraged positions built around Aave.
That distinction is important because the exploit shows how a secure base protocol can still become part of a loss when an additional contract is granted powerful permissions above it.
According to SlowMist’s incident analysis, the FlashLoopAdapter suffered from an access-control weakness that allowed an attacker-controlled contract to impersonate a legitimate Safe for the purpose of passing its authorization check.
The Fake Safe Was Allowed to Authenticate Itself
The central problem was how FlashLoopAdapter decided whether its caller was authorized.
The adapter was built to work with Safe wallets that had enabled it as a module. Rather than independently proving that the caller was one of those legitimate Safes, the contract effectively asked the caller whether the adapter was enabled.
That creates an obvious trust problem when the caller itself may be malicious.
An attacker could deploy a fake Safe-like contract programmed to return the answer the adapter expected. When FlashLoopAdapter checked whether it was enabled, the malicious contract simply reported that it was.
The adapter then treated the caller as authorized even though the attacker-controlled contract was not one of the real victim Safes.
The weakness resembles a broader class of authorization failures in which software trusts information supplied by the entity it is attempting to authenticate. The identity check exists in code, but the source of truth behind it is controlled by the attacker.
Attacker-Controlled Swap Data Turned the Module Into an Execution Route
Passing the initial authorization check was only the first step.
SlowMist said the adapter also allowed the caller to control both swapRouter and swapCalldata. That flexibility was intended to support swaps while opening or closing leveraged positions, but it gave the attacker a route to direct the module toward another contract with attacker-selected instructions.
The attacker set the target to a real victim Safe and constructed calldata that invoked execTransactionFromModule().
That function is powerful because Safe modules are specifically designed to execute certain transactions without collecting the normal set of owner signatures each time. The Safe had already trusted FlashLoopAdapter by enabling it.
As a result, once the vulnerable adapter was manipulated, calls originating from it could arrive at the real Safe carrying authority the Safe itself had previously granted.
This is where the exploit crossed from a weakness in the fake caller into a loss for legitimate wallets.
A Morpho Flash Loan Helped Unwind the Aave Positions
The attacker also used a large WETH flash loan from Morpho as part of the transaction sequence.
The borrowed WETH was used to repay debt associated with the victims’ leveraged Aave v3 positions. Repaying that debt released collateral that had previously been locked against the borrowing position.
The manipulated Safe-module execution path could then be used to move the released collateral out of the affected Safes.
SlowMist said weETH was ultimately extracted from two Safe wallets, with the attacker retaining approximately 114.09 ETH in value after completing the broader transaction sequence.
The flash loan was therefore an enabling source of temporary liquidity rather than the underlying vulnerability. Removing Morpho from the transaction would not fix the authorization bug. The weakness existed because FlashLoopAdapter could be convinced that a malicious caller was legitimate and could subsequently direct privileged calls toward Safes that had enabled the module.
Aave v3 and Safe’s Core Contracts Were Not the Exploited Systems
Aave founder Stani Kulechov said Aave v3 itself was unaffected, describing FlashLoopAdapter as an external adapter built on top of the lending protocol.
That fits SlowMist’s technical description. Aave processed debt repayment and collateral withdrawal instructions according to its normal rules. The problem was how authority to initiate those operations was obtained.
Safe’s core multisig design presents a similar distinction. The victims had enabled a module capable of acting through their Safes, and the attacker found a way to misuse that trusted module.
This matters because crypto incidents are often attributed to the largest protocol visible in the transaction path. Aave appears in the leveraged position, Morpho provides the flash liquidity and Safe holds the assets, but none of those facts alone identifies the vulnerable component.
Dave Finances recently examined the same distinction after Bitget’s underlying wallet keys remained intact while surrounding authorization infrastructure was compromised. The security boundary that fails is not always the one holding the asset directly.
The Real Exposure Question Is How Many Safes Enabled FlashLoopAdapter
The immediate loss is relatively contained by DeFi standards. The more important unanswered question is the adapter’s deployment footprint.
A Safe module only has this kind of authority when a wallet has actively enabled it. That should limit exposure to Safes using the specific integration rather than Aave users or Safe users generally.
But there is not yet a clear public count of how many wallets had FlashLoopAdapter enabled.
If only the two affected Safes used it, the incident may remain a narrowly contained custom-integration failure. If the same adapter was deployed across a larger set of leveraged-position strategies, additional wallets could theoretically share the same authorization weakness until the module is disabled, replaced or otherwise secured.
That blast-radius question has become increasingly important as DeFi applications reuse common components. A recent Cosmos EVM vulnerability demonstrated how shared software can expose multiple otherwise separate blockchain deployments when the same flawed component appears across systems.
The same principle applies at wallet level: the value of identifying a vulnerable module is not only understanding who has already lost money, but identifying everyone else who granted the same code authority.
Composability Creates Security Dependencies Users Rarely See
The deeper lesson here is uncomfortable for DeFi because FlashLoopAdapter was doing exactly the kind of thing composable finance is designed to make possible.
A user can combine a Safe, Aave lending markets, liquid-staking collateral, swap infrastructure and automated looping logic into one strategy. Each component provides a narrow function, and smart contracts connect them into something far more powerful.
But permissions also compose.
When a Safe enables a module, it is not simply installing a convenience feature. It is extending part of the wallet’s authority to another contract. If that contract subsequently trusts a router, callback, caller or arbitrary calldata field too broadly, the security assumptions of the entire stack change.
That is why auditing the largest protocols is not enough.
Aave can operate correctly. Safe can verify module-originated calls correctly. Morpho can issue and recover a flash loan correctly. Every major component can behave as designed, and money can still disappear because the contract connecting them makes one incorrect assumption about who is allowed to call it.
Other recent security cases have made the same point from different directions. Dave Finances reported how a malicious application could threaten crypto wallets even without exploiting the wallets’ own cryptographic design. The dangerous layer can sit above, below or beside the system users believe they are trusting.
The Fake Safe Technique Is the Part Developers Should Remember
The most interesting element of this exploit is not the flash loan or even the $305,000 loss.
It is the authentication model.
The adapter effectively relied on a contract controlled by the caller to provide evidence that the caller should be trusted. Once the attacker realized that, creating a fake contract that always returned the desired answer turned the check into little more than a formality.
That is a small coding assumption with a large security consequence.
And once the attacker passed that boundary, composability did the rest: the vulnerable adapter had sufficient flexibility to turn attacker-controlled routing data into a privileged call against real Safes, Aave positions could be unwound, and temporary Morpho liquidity made the entire sequence possible inside a coordinated transaction flow.
For Aave users generally, the evidence currently points away from a core protocol problem. For Safe users generally, there is likewise no evidence of a multisig-wide vulnerability.
The unresolved risk sits in the middle.
How many Safes trusted this particular adapter, and how many other DeFi modules rely on similarly circular authorization assumptions?
The $305,000 already lost answers the first question only partially. The second is the much larger security issue.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.