Summer Finance drained of roughly $6M in ongoing flash loan exploit
Security & Exploits ·
An attacker used a large Morpho flash loan to manipulate vault accounting on Summer Finance's Lazy Summer Protocol, extracting close to $6 million so far.
The incident was first flagged in a post by Vladimir S. on X, who reported an active exploit draining funds from Summer Finance in real time. According to the transaction trace, the attacker borrowed 65.419 million USDC and 1 million USDT from Morpho, then cycled that liquidity through public Lazy Summer and VaultV2 functions — deposit, redeem, withdrawFromArks, withdrawFromBuffer and forceDeallocate — to exploit how the protocol tracked vault and Ark balances within a single transaction.
The mechanism did not involve a compromised key or misuse of admin privileges. Instead, the attacker minted and redeemed LVUSDC while the protocol's same-transaction accounting and liquidity assumptions were thrown off across FleetCommander, Arks, VaultV2 and Morpho-linked adapters. Once the flash loans were repaid, the exploiter swapped leftover USDC through Curve and moved 6,016,754.998 DAI to the address 0x7BF716167B48CF527725722C6d79494b45B3BDCa. Because the exploit contract itself is unverified, the precise custom logic behind the attack has been reconstructed from on-chain traces and log data rather than confirmed source code, and the behavior is also consistent with a known ERC-4626 donation or inflation attack pattern.
The event has been corroborated across multiple outlets. The Block reported the exploit was tied to flash loan liquidity manipulation involving Curve's DAI/USDC pools, while WuBlockchain and Leviathan News both described the attack as routed through a 65.4 million flash loan against the Lazy Summer Protocol. In total, nine distinct sources have covered the incident, with the loss figure consistently cited at roughly $6 million.
What remains unresolved is whether Summer Finance can recover any of the drained funds or whether the protocol will pause affected contracts. The exploit contract's unverified status also means the full custom logic behind the accounting manipulation has not been independently confirmed, leaving open questions about whether similar vault architectures elsewhere carry the same same-transaction accounting risk.