SolutionsProductsAuditsBlogContactRequest an Audit
BlogThe Biggest Flash Loan Attacks That Changed DeFi
The Biggest Flash Loan Attacks That Changed DeFi
security-analysis9 min readAugust 24, 2026
0xTeam Author
Share

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:

A flash loan is usually not the vulnerability. It is the amplifier. The vulnerability is typically somewhere else.

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:

FLASH LOAN → CREATE LEVERAGED POSITION → MANIPULATE THE POSITION'S ACCOUNTING STATE → CREATE AN INSOLVENT ACCOUNT → LIQUIDATE FOR PROFIT → REPAY FLASH LOAN

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:

FLASH LOAN → TEMPORARILY ACQUIRE GOVERNANCE POWER → PASS MALICIOUS PROPOSAL → EXECUTE MALICIOUS ACTION → TRANSFER ASSETS → REPAY FLASH LOAN

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
The key question is: what happens if an attacker can temporarily acquire enough voting power to control the protocol? If the answer is "they can immediately execute a treasury-draining proposal," the governance model has a serious security problem.

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:

BORROW TEMPORARY CAPITAL → MANIPULATE MARKET CONDITIONS → INTERACT WITH THE VAULT → EXPLOIT DISTORTED ACCOUNTING → EXTRACT PROFIT → REPAY BORROWED CAPITAL

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:

Temporary capital was used to create a state the protocol was never designed to handle safely.

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.

Do not design security around the assumption that attackers lack capital. In DeFi, they may only need it for one block.

One vulnerability. One transaction. One flash loan. And that can be enough to change an entire protocol.

Flash loans don't create the bug. They give attackers the capital to exploit it.
++
Worried? Get your security audit done today.

Don't launch vulnerable code. Our team will review your smart contracts and deliver a full audit report within 48 hours.

Request Audit

Tags

security-analysisDeFiSecurityWeb3

Get Audited

Protect your protocol before attackers do. Request a full smart contract audit from 0xTeam.

Request Audit
© 0xTeam space 2026. All rights reserved.