Famous Flash Loan Exploit Analyses

Flash loans have revolutionized decentralized finance (DeFi) by enabling permissionless, collateral-free loans that must be repaid within a single transaction. While they power advanced arbitrage and yield strategies, they have also been exploited, resulting in multi-million‐dollar losses. In this extensive article, we dissect some of the most notorious flash loan exploits, detail their mechanics, root causes, impacts, and lessons learned.

1. What Is a Flash Loan

Definition: A loan issued and repaid within one blockchain transaction.
Use Cases: Arbitrage, collateral swaps, liquidation protection.
Risks: Atomicity can be weaponized, especially when combined with oracles and lending pools.

2. Anatomy of a Flash Loan Exploit

Borrow: Attacker requests a large flash loan (e.g., 100M USD in tokens).
Manipulate: They exploit a vulnerability – oracle manipulation, pricing errors, or reentrancy.
Profit: They drain funds from liquidity pools or mint tokens abusively.
Repay: Finally, repay the flash loan within the same transaction, pocketing the difference.

Table of Notable Flash Loan Exploits

Date	Protocol	Loss (USD)	Exploit Type	Root Cause
Feb 2020	bZx	350k 645k	Oracle Manipulation	Single-source price feed
Oct 2020	Harvest Finance	24M	Liquidity Pool Price Attack	Unbalanced pool oracles
Feb 2021	Alpha Homora	37M	Price Oracle Exploit	Unverified oracle integration
May 2021	PancakeBunny	200M	Pump-and-Dump	Manipulated internal price
Aug 2021	Cream Finance	130M	Reentrancy Flash Loan	Missing reentrancy guard

Detailed Case Studies

2.1 bZx (February 2020)

bZx was among the first high‐profile flash loan hacks. The attacker borrowed 10,000 ETH from dYdX, then used it to take a short position on Synthetix. By manipulating Kyber’s on-chain price oracle for WBTC, they inflated the price on one side of the trade, triggering a profitable liquidation. The flash loan was repaid, netting roughly 350k first, and later another 645k in a second attack.

Root Cause: Reliance on a single, low‐liquidity on-chain price feed. Anyone could influence the price with minimal capital.

Mitigation: Multi-source oracles like Chainlink or time‐weighted average prices (TWAP).

2.2 Harvest Finance (October 2020)

Harvest pools deposited stablecoins into Curve and other AMMs to optimize yields. The exploiters used a flash loan to massively swap USDT/USDC for USDC/DAI within a few blocks, skewing the pool’s internal price. The protocol overvalued the deposits, enabling the attacker to mint underpriced tokens, then drain the pool for 24M.

Root Cause: Using pool snapshots without slippage guards made pricing oracle susceptible to sudden trades.

Mitigation: Implement slippage limits, guard rails on token minting based on price variance.

2.3 Alpha Homora (February 2021)

Alpha Homora allowed leveraged yield farming via flash loans. The attack manipulated prices on Iron Bank markets, using unverified oracles. A flash loan of ≈11M was used to inflate the collateral value of WBTC, borrow stablecoins, and exit with a net profit of 37M.

Root Cause: Oracle integration without cross verification automatic borrowing limits not updated.

Mitigation: Decentralized oracles, manual rate updates, and borrowing limits per asset.

2.4 PancakeBunny (May 2021)

PancakeBunny’s vaults auto‐compounded farming rewards. The attacker borrowed a large amount of BUNNY via a flash loan, dumped it on PancakeSwap to crash prices, bought back cheap tokens, repaid the loan, and drained 200M from the vaults.

Root Cause: Internal price variable for rewards calculation was manipulable in the same block.

Mitigation: Use on-chain oracles or time-delay for price updates, implement emergency stop functions.

2.5 Cream Finance (August 2021)

Cream Finance, a Compound fork, suffered multiple flash loan attacks. In one, an attacker exploited a reentrancy vulnerability in a wrapped token, combining it with a flash loan to drain 130M. The attacker repeatedly called the vulnerable function before balances updated, extracting excessive tokens.

Root Cause: Missing reentrancy guards in reward/redeem functions, no flash loan detection.

Mitigation: OpenZeppelin’s ReentrancyGuard, checks‐effects‐interactions pattern, flash loan detectors.

Common Vulnerabilities Preventative Measures

Oracle Manipulation: Use decentralized oracles with high liquidity and TWAP.
Reentrancy: Employ reentrancy guards and follow checks‐effects‐interactions.
Slippage Controls: Set maximum slippage thresholds for critical swaps.
Access Controls: Admin functions should be time-locked and multisig-protected.
Flash Loan Detection: Integrate libraries that detect and block flash loan patterns.
Audit Bug Bounties: Engage multiple reputable auditors and incentivize white-hat disclosures.

Famous Flash Loan Exploit Analyses