
The Biggest Flash Loan Attacks That Changed DeFi
Euler ($197M), Beanstalk ($77M), and Harvest ($24M) all show the same truth: a flash loan is rarely the vulnerability — it's the amplifier. How temporary capital turns a flawed protocol assumption into a drain, and why you should never treat an attacker's capital as a security boundary.
Euler Finance. Beanstalk. Harvest Finance.
Flash loans changed one of the fundamental assumptions behind financial attacks. Traditionally, exploiting a financial protocol at scale required capital. A trader manipulating a market might need millions of dollars. An attacker attempting to influence governance might need to buy a significant percentage of a token's supply.
A DeFi attacker may not need to permanently own that capital. With a flash loan, they can borrow it, use it, and repay it — all within a single blockchain transaction. That makes flash loans extremely powerful. But there is an important distinction that often gets lost after a major exploit:
It may be in:
- Accounting logic
- Governance design
- Price calculations
- Collateral mechanisms
- Liquidation logic
- Liquidity assumptions
The flash loan simply gives the attacker enough temporary capital to exploit that weakness at scale. Some of DeFi's most important security incidents demonstrate exactly how this works.
01 — Euler Finance: $197 Million
March 13, 2023. Euler Finance suffered one of the largest DeFi exploits of 2023. Approximately $197 million in assets was extracted from the protocol during the attack. Euler Finance and Chainalysis both documented the incident at roughly that figure. The attacker used flash-loaned capital as part of a carefully constructed sequence involving Euler's own lending mechanisms. The attack exploited a vulnerability associated with the protocol's donateToReserves() functionality.
What Happened?
The attacker used the protocol's mint() functionality to build highly leveraged positions. They then used the vulnerable donateToReserves() mechanism to reduce collateral without a corresponding health check that would have prevented the resulting position from becoming dangerously insolvent. A second account could then liquidate that position and acquire assets at a discount. The attack was repeated across multiple asset pools.
CertiK's incident analysis described the exploit as involving malicious flash loans, highly leveraged positions, and the vulnerable donateToReserves() function, resulting in approximately $197 million in losses. The attack pattern was roughly:
The Important Lesson
The flash loan did not create the vulnerability. The vulnerability existed in the protocol's accounting and liquidation logic. The flash loan made it possible to execute the attack with a much larger amount of capital. This is one of the most important lessons in DeFi security: attackers do not test functions individually. They test combinations.
A function may appear safe in isolation. The exploit may only appear when an attacker combines it with leverage, borrowing, liquidation, another account, or a flash loan. The incident also had an unusual ending — Euler later confirmed that recoverable funds were returned following negotiations with the attacker.
02 — Beanstalk: A Flash Loan Governance Takeover
April 17, 2022. The Beanstalk attack demonstrated that flash loans can manipulate more than token prices. They can also temporarily manipulate governance power. The attacker used a flash loan to obtain enough voting power to exploit Beanstalk's then-existing on-chain governance mechanism.
Beanstalk's own disclosures state that approximately $77 million in non-Bean assets were stolen in the attack. Some analyses reported a higher total economic impact — around $182 million — based on broader valuation methodologies and the protocol's affected assets. Because these figures measure different things, using ~$77 million stolen, based on Beanstalk's own current disclosure, is the clearest figure for the direct theft.
What Happened?
The attacker borrowed an enormous amount of assets through flash loans. This temporary capital allowed them to obtain sufficient governance power to approve a malicious proposal. The sequence was essentially:
Beanstalk later confirmed that the attacker had used a flash loan to compromise the governance mechanism and transfer deposited assets to an attacker-controlled address.
What Failed?
The fundamental problem was that governance power could be acquired and used immediately. The system did not sufficiently distinguish between long-term governance participation and temporary ownership created with borrowed capital. A flash loan made it possible to acquire significant influence at exactly the moment it was needed.
The Security Lesson
Governance mechanisms controlling large amounts of capital should not blindly assume that current token ownership represents genuine, long-term governance participation. Potential protections include:
- Voting delays
- Timelocks
- Execution delays
- Emergency cancellation mechanisms
- Additional review for high-risk proposals
- Governance models that reduce the impact of temporary token ownership
03 — Harvest Finance: Approximately $24 Million
October 2020. Harvest Finance was one of the early examples of how flash liquidity could amplify an economic weakness in a DeFi protocol. The attacker targeted Harvest's vault strategy by manipulating the market conditions and exploiting how the protocol calculated the value of deposited assets. Harvest's own post-incident update discussed the attack as an economic exploit involving flash-loan-driven manipulation and mitigation efforts. The commonly reported loss from the exploit was approximately $24 million, with the attacker returning a portion of the funds afterward.
What Happened?
The attacker used flash liquidity to rapidly manipulate the relative prices of assets in the Curve Y pool. The attack exploited how Harvest's vaults handled deposits and withdrawals during these distorted market conditions. The attacker could manipulate the environment, interact with the vulnerable accounting logic, and extract value before the market conditions normalized. The simplified attack looked like:
The Security Lesson
A protocol should never assume that market conditions will remain normal during a transaction. An attacker may be able to create extreme conditions that would never occur naturally. Security teams need to ask:
- What happens if liquidity suddenly increases dramatically?
- What happens if a pool's balance changes significantly?
- What happens if prices move sharply within one transaction?
- Can deposits and withdrawals exploit those temporary conditions?
The attacker does not need to wait for the market to become abnormal. They can create the abnormal market themselves.
What These Attacks Had in Common
Euler, Beanstalk, and Harvest were very different exploits. Euler involved vulnerable accounting and liquidation mechanics. Beanstalk involved governance manipulation. Harvest involved economic and price manipulation. But each attack followed a similar principle:
01 — Find the Assumption
The attacker identifies an assumption such as: "Users cannot access this much capital." "Governance tokens represent long-term ownership." "Prices will not move this dramatically." "Liquidity will remain relatively stable."
02 — Borrow the Capital
A flash loan removes the need to permanently own the capital required to challenge that assumption.
03 — Create an Artificial State
The attacker temporarily changes something the protocol relies on: price, liquidity, governance power, collateral position, or internal accounting.
04 — Extract Value
Once the protocol accepts the manipulated state, the attacker can borrow assets, liquidate positions, withdraw funds, or execute governance actions.
05 — Repay the Loan
The borrowed funds are returned. The transaction completes. The attacker keeps the difference.
Why Flash Loans Changed DeFi Security
Flash loans changed the economics of exploitation. Before flash loans, some vulnerabilities might have been impractical because exploiting them required enormous amounts of capital. Flash loans can change "an attacker would need $100 million" into "an attacker needs to successfully execute one transaction."
That means protocol designers should no longer treat the attacker's capital as a meaningful security boundary. A better assumption is: assume the attacker can temporarily access whatever liquidity exists in the ecosystem. Then ask: does the protocol remain secure?
How to Reduce Flash Loan Risk
There is no universal flashLoanProtection() function. The goal is to remove the underlying condition that makes the flash loan useful.
1. Do Not Trust Same-Transaction Price Movements
Avoid using easily manipulated spot prices for critical calculations. Where appropriate, use TWAPs, robust oracle networks, and multiple independent data sources.
2. Separate Governance Power From Instant Liquidity
For governance systems: add timelocks, delay execution, review high-impact proposals, and consider voting mechanisms resistant to temporary capital.
3. Test Economic Edge Cases
Traditional testing asks: does the function work? Security testing should also ask: what happens if an attacker has $1 billion for one transaction?
4. Test Function Combinations
Attackers chain functions together. Audits should examine sequences involving:
- Deposit → Borrow → Donate → Liquidate
- Buy → Vote → Execute
- Manipulate → Deposit → Withdraw
The vulnerability may exist in the interaction.
5. Limit the Blast Radius
Consider borrowing caps, withdrawal limits, circuit breakers, rate limits, and emergency pause mechanisms. These controls may not prevent an exploit entirely. But they can significantly reduce the amount of value an attacker can extract.
Final Thoughts
Flash loans are not inherently malicious. They are a financial primitive. The real danger appears when enormous temporary capital meets a flawed protocol assumption.
Euler showed how a flash loan could amplify broken accounting and liquidation logic. Beanstalk showed how temporary capital could become temporary governance control. Harvest showed how flash liquidity could create artificial market conditions and exploit vulnerable accounting.
One vulnerability. One transaction. One flash loan. And that can be enough to change an entire protocol.
Don't launch vulnerable code. Our team will review your smart contracts and deliver a full audit report within 48 hours.
Related Posts
Tags
Get Audited
Protect your protocol before attackers do. Request a full smart contract audit from 0xTeam.
Request Audit

