How a Fake Aave Upgrade Let an Attacker Drain $14M From Furucombo Users

On Monday, March 1, 2021, an attacker exploited DeFi aggregator Furucombo, draining roughly $14 million from wallets that had granted the app "infinite approval" over their tokens.

Infinite approval means a user hands a protocol unlimited, standing permission to move their tokens — a convenience that trades away the "don't trust, verify" principle DeFi is supposed to run on, since re-approving a fixed amount every time is itself a gas expense few users want to pay. Furucombo users had granted varying levels of approval, and many of the largest grants proved the most costly.

How the exploit worked

The attacker tricked the Furucombo proxy contract into believing that Aave V2 had deployed a new implementation — a classic "evil contract" pattern. That fake implementation was designed to redirect every approved token it could reach to addresses the attacker controlled, since users had already authorized the Furucombo contract to move funds on their behalf.

Researcher Kurt Barry walked through the mechanics: one of the fund-draining transactions was routed to the Furucombo proxy, naming the Aave V2 Lending Pool proxy as the "handler" for its single action. The ethtx.info execution trace shows nested delegatecalls at work. Handlers need registry approval to function, and at the moment of the attack, this particular proxy was still listed as valid.

The Furucombo proxy delegatecalled into the Aave V2 proxy, which then pulled an implementation address from a specific storage slot. Because the call was a delegatecall, that read happened against the Furucombo proxy's own storage rather than Aave's — and the address sitting in that slot was the attacker's malicious contract.

A preceding transaction shows how that slot got poisoned in the first place: the attacker used their own contract to make the Furucombo proxy delegatecall the Aave V2 proxy's initialize function, which set the implementation slot to point at the exploit contract.

From there, every subsequent delegatecall ran the attacker's code inside the Furucombo proxy's own storage context. One victim, for instance, had approved the proxy to spend their stETH — and that stETH was swept straight to the attacker. The same pattern repeated across many victims.

Root cause, in short:

• The Furucombo proxy allowed callers to specify which trusted "handler" it would delegatecall, exposing its storage to modification.
• A handler itself performed a caller-specified delegatecall to an address pulled from storage.
• That same handler exposed a function letting anyone set that storage address.

Lessons drawn from the incident:

• A registry of "trusted" contracts reduces risk but is not a guarantee of safety.
• Developers need to audit how a delegatecall target can alter the caller's own storage.
• Restricting which functions or parameters a callee can invoke limits blast radius.
• User-supplied inputs into sensitive call paths deserve extra scrutiny.

The damage wasn't limited to individual wallets — Cream Finance also took a hit, with the attacker effectively "borrowing" straight out of its treasury.

Researcher Igor Igamberdiev compiled the list of stolen assets:

• 3,900 stETH
• 2.4M USDC
• 649,000 USDT
• 257,000 DAI
• 26 aWBTC
• 270 aWETH
• 296 aETH
• 2,300 aAAVE
• 4 WBTC
• 90,000 CRV
• 43,000 LINK
• 7,300 cETH
• 17.2M cUSDC
• 69 cWBTC
• 142.2M BAO
• 38,600 PERP
• 30,400 COMBO
• 75,000 PAID
• 225,000 UNIDX
• 342 GRO
• 19,000 NDX

A victim's account

One of the hardest-hit users, DeFi participant Limzero (@pleyuh), described the experience. He first learned of the attack through a Telegram post from Darren's "The daily ape" channel while at home with friends. Checking a wallet he had used with Furucombo, he saw his aAAVE and part of his aETH already gone.

With active loans outstanding, his immediate fear was liquidation — his health factor had dropped to 1.15, prompting him to repay quickly. He noted that the attacker took all of his aAAVE but only about a third of his aETH, and suspects his low health factor may have blocked further withdrawals, making the outstanding loans an inadvertent stroke of luck.

After securing his position, he revoked every token permission tied to that address — an action he'd been putting off for weeks while waiting for lower gas fees. He discovered the theft about 90 minutes after it occurred.

He described the loss as significant in absolute terms but survivable for his overall portfolio, and said the scariest moments were the few minutes he spent unsure whether his positions would be liquidated. He called the episode an expensive but ultimately useful security lesson, noting it was the first smart-contract exploit to touch him personally (aside from the earlier COVER incident, which he'd nearly forgotten). He said the event hadn't diminished his confidence in DeFi generally, since these categories of risk were already known, though it did prompt him to tighten his personal security practices — details he preferred to keep private.

Asked what he'd recommend to other users, he listed: using hardware wallets, avoiding Windows machines, keeping a dedicated device for contract interactions, using unique passwords or a password manager plus a VPN, keeping a low social-media profile, spreading funds across multiple addresses, using fresh addresses for new farms, and regularly revoking approvals on frequently used addresses — caveating that he's not a security professional and these are standard community-sourced guidelines. He also suggested keeping a portion of holdings on reputable centralized exchanges such as Kraken, Coinbase, Gemini, or Binance as a hedge against a compromised personal wallet.

Takeaway

The fix for this class of exploit is straightforward in principle: avoid granting infinite approval unless the counterparty has earned unlimited trust. Repeated fixed-amount approvals cost more in gas, but that cost is trivial next to the risk of a mass drain. Tools like Debank and Etherscan's token approval checker let users audit and revoke standing approvals — a task worth doing promptly rather than deferring, as this incident illustrated.

Update, July 18, 2021: Auditor Haechi provided the following statement regarding its prior audit of Furucombo's contracts:

Although their contract (proxy) was in our scope of audit, the exploit that infected the proxy was not our scope of the audit.

What furucombo team provided to us was only two contracts; furucombo proxy and compound adapter. So their scenario that furucombo team has provided is accessing the compound protocol using a compound adapter with proxy, that's all.

But, as you know, the exploit was caused by the scenario of using AAVE. We were not able to find this issue since they already had whitelist functionality which should have worked as a guard for this kind of situation.