Third-Party Aave Adapter Exploit Drains 114 ETH—Core V3 Contracts Unaffected

A thief drained roughly 114 ETH through a third-party tool built on top of Aave, but the distinction that matters is where the failure actually happened: not inside Aave v3.

According to CryptoSlate, the target was a Loop Safe Module adapter called FlashLoopAdapter. The tool was designed to help users build leveraged positions, but its access-control check could be fooled by a malicious contract pretending to be an approved Safe.

That let the attacker reach the adapter’s swap logic and redirect assets. Security firm SlowMist estimated the loss at about 114.09 ETH and traced the weakness to a check that trusted the calling contract’s answer instead of independently proving that the caller was legitimate.

🚨SlowMist TI Alert🚨

💸 @aave v3 Loop Safe Module Loss: ~114.09 ETH

🔍 Root Cause: FlashLoopAdapter’s open()/close() access control only checks ISafe(msg.sender).isModuleEnabled(address(this)), which is spoofable via a fake Safe that always returns true. Its _swap() then…

— SlowMist (@SlowMist_Team) October 2, 2026

The technical lesson is narrow but important. Smart-contract risk does not stop at the protocol boundary.

A lending market can be operating as designed while an outside adapter, automation module or convenience layer introduces a separate route to user funds.

Aave founder Stani Kulechov moved quickly to separate the adapter from the core protocol. He said the incident involved an external tool built on top of Aave and had “zero effect” on Aave v3.

This is not Aave v3 contract, it’s third party external adapter built on top of Aave, zero effect on Aave v3.

— Stani (@StaniKulechov) October 2, 2026

The risk was in the extra layer. That clarification is more than reputation management.

DeFi users often see an integration carrying a familiar protocol name and assume every component inherits the security of the underlying system. It does not.

Adapters can have their own permissions, upgrade paths, audits and assumptions.

In this case, the vulnerable check asked a caller whether the adapter had been enabled. A hostile contract could simply answer yes.

Once that trust boundary failed, the attacker could use the adapter’s approved powers in a way its designers never intended.

The incident is also a reminder that “non-custodial” does not mean “risk-free.” Users may retain control of a wallet while still granting powerful permissions to modules that can move or swap assets. Every added layer creates another piece of code that must be reviewed and monitored.

What Aave users should watch. There is no indication from the reporting or the project’s response that Aave v3 itself was compromised.

Users should avoid panic-driven moves based on headlines that blur the adapter and the core contracts together.

Anyone who used the affected Loop Safe Module should review approvals, positions and transaction history. The practical question is whether a wallet authorized the specific third-party adapter involved in the exploit.

For the broader market, the episode strengthens the case for treating integrations as independent security products. A blue-chip protocol can reduce one category of risk, but it cannot automatically secure every external tool that plugs into it.

The 114 ETH loss is meaningful. The more useful takeaway, though, is precise: the breach hit an added convenience layer, and users need to judge that layer on its own code—not on the name of the protocol beneath it.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.