Flash Loan Attacks: How They Exploit DeFi Smart Contracts

Flash loan attacks exploit DeFi smart contracts by using uncollateralized borrowing inside one blockchain transaction to amplify a weakness in price logic, accounting, governance, or liquidation rules. The flash loan is not the bug. The bug is usually an assumption: that an attacker cannot access hundreds of millions in temporary liquidity, move a pool price, vote with borrowed tokens, or push rounding math into an extreme state.

That assumption is now unsafe. OWASP's Smart Contract Top 10: 2026 lists flash loan facilitated attacks as SC04, treating them as a systemic smart contract security risk rather than a niche DeFi trick. If you build lending markets, vaults, AMMs, NFT lending, or governance modules, assume an attacker can borrow large capital for one atomic call path and return it before the transaction ends.

What Is a Flash Loan?

A flash loan is an uncollateralized loan that must be borrowed and repaid within the same transaction. If repayment fails, the whole transaction reverts. That is why lenders can offer it without collateral. The borrower either repays by the end of the transaction or, from the chain's point of view, the loan never happened.

Flash loans are legitimate. Traders use them for arbitrage, collateral swaps, liquidations, and refinancing. A developer using Aave v3 can call flashLoanSimple on the Pool contract, receive assets in executeOperation, do the work, then approve repayment of amount + premium. Miss that final approval and the transaction fails. In older ERC-20 integrations, the trace often ends with a very plain error: ERC20: insufficient allowance. Small detail, big headache.

How Flash Loan Attacks Work

Most flash loan attacks follow the same sequence, although the transaction trace can involve dozens of contracts.

1. Borrow: The attacker borrows a large amount from a flash loan provider such as Aave, or takes flash liquidity from a DEX.
2. Manipulate: The attacker changes a price, reserve ratio, governance balance, accounting variable, or liquidation condition.
3. Extract: The vulnerable protocol gives the attacker too many assets, accepts bad collateral, mints too many shares, or allows a malicious action.
4. Repay: The attacker repays the loan in the same transaction and keeps the surplus.

Atomicity is the key. The transaction either succeeds as one bundle or reverts as one bundle. That lets attackers test complex paths against forks before sending a profitable transaction to mainnet or a layer 2.

Why DeFi Smart Contracts Are Exposed

DeFi smart contracts are exposed because they compose with other contracts. That is the strength of DeFi, and also the trap. A vault may trust an AMM spot price. A lending protocol may trust a token's on-chain liquidity. A governance module may count balances at the wrong time. A share accounting function may behave safely under normal deposits, then fail when reserves are pushed to absurd ratios.

Flash loans break two common assumptions:

• Capital is costly: Designers assume no attacker can cheaply control a large position for one block.
• Balances show commitment: Governance and collateral systems assume a large token balance reflects real economic exposure.

Both assumptions are weak. If your protocol is safe only because an attack would require too much upfront capital, it is probably not safe.

Main Flash Loan Attack Vectors

Oracle Manipulation

Oracle manipulation is the most common pattern. The attacker uses borrowed funds to move the price in a thin AMM pool, then a protocol reads that distorted price as truth. The result can be under-collateralized borrowing, bad liquidations, or inflated collateral value.

The fix is not just "use an oracle." Use the right oracle design. Time-weighted average prices, multiple data sources, liquidity checks, and bounded price changes reduce single-transaction manipulation. A one-pool spot price is not an oracle. It is an invitation.

AMM and Liquidity Drainage

AMMs can be attacked when pricing, slippage, or share minting logic behaves badly at extreme reserve ratios. OWASP documents a case where a rounding issue in withdrawals became dangerous only after a flash loan pushed an AMM pool into an unusual state. The attacker borrowed 3 million USDT, drove the active USDC balance down to 28 wei, then ran 44 small withdrawals that burned less liquidity than the assets removed. That is the kind of edge case normal unit tests rarely catch.

Governance Attacks

If voting power can be acquired and used in the same block, flash loans can turn governance into an attack surface. An attacker can borrow governance tokens, pass a malicious proposal, change risk parameters, whitelist a contract, or redirect treasury assets. Mature protocols use vote snapshots, holding periods, timelocks, and delayed execution to reduce this risk.

Reentrancy Combined With Flash Loans

Reentrancy is old, but flash loans make it sharper. Large temporary capital allows repeated calls to withdrawal or accounting functions before state has settled. Use checks-effects-interactions, update state before external calls, and apply reentrancy guards where external calls touch funds. Solidity 0.8.x protects against arithmetic underflow by default, but it does not save poor state ordering.

Cross-Protocol Composability Exploits

The hardest attacks are multi-protocol chains. A lending market reads a DEX price. A vault token is used as collateral elsewhere. A liquidation bonus depends on a pool state changed earlier in the same transaction. Attackers now chain 40 or more contract calls in a single exploit path, according to recent DeFi security analyses. Manual review alone struggles here.

Real-World Flash Loan Attack Examples

Reported losses vary because researchers define flash loan attacks differently. OWASP's 2026 materials cite 33.8 million dollars in documented losses across more than 90 analyzed incidents. Other industry resources use broader definitions and place cumulative losses much higher, including more than 500 million dollars in flash loan exploit losses and broader flash attack estimates in the billions.

Euler Finance

The 2023 Euler Finance exploit is often cited as one of the largest flash loan related incidents, with around 197 million dollars taken. The attack combined flash loan liquidity with complex lending logic to create and liquidate unhealthy positions for profit. Euler later recovered funds, but the case still changed how teams think about economic attack simulation.

Makina Finance

Security reports covering the January 2026 Makina Finance incident describe a flash loan based price manipulation attack that stole 1,299 ETH, worth roughly 4 million dollars at the time. The reported flow involved a 280 million USDC flash loan, manipulation of a MachineShareOracle, and mispriced pool operations that let the attacker drain more than 1,000 ETH before repayment.

Bunni, Shibarium, and Earlier DeFi Incidents

Bunni reportedly ceased operations after an 8.4 million dollar flash loan attack. Shibarium suffered a separate 2.4 million dollar token loss tied to flash loan based manipulation. Earlier incidents involving Akropolis, Cheese Bank, Value DeFi, and Origin Protocol showed the same pattern: borrowed liquidity amplified flaws in oracle design, pool accounting, or protocol assumptions.

How to Defend DeFi Smart Contracts

Design as if the Attacker Has Unlimited One-Block Capital

This is the practical rule. Do not ask, "Who would have enough money to do this?" Ask, "What happens if someone has the money for one transaction?" That question changes the design.

• Do not rely on one AMM pool's spot price for collateral valuation.
• Reject price updates that move beyond reasonable thresholds in one block.
• Use TWAPs, independent oracle feeds, and liquidity-weighted checks.
• Model extreme reserve ratios during tests.
• Set conservative loan-to-value ratios for illiquid assets.

Test Accounting at the Edges

Most protocol-draining bugs hide in accounting. Share minting, share burning, rounding direction, fee accrual, and donation handling all need adversarial tests. Use Foundry invariant tests or Hardhat mainnet forks to simulate large flash loan flows. Do not test only "normal user deposits 100 USDC." Test dust balances, 1 wei reserves, very large deposits, and repeated small withdrawals.

Protect Governance

Governance should not be instant. Use voting snapshots, quorum rules, timelocks, proposal review windows, and delayed execution. If a token can be borrowed and immediately used to pass a proposal, the protocol is exposed.

Monitor Runtime Behavior

Pre-deployment audits are necessary, but they are not enough. Add monitoring for suspicious borrow-manipulate-withdraw-repay patterns, abnormal oracle movement, sudden liquidity shifts, and contract call chains that touch multiple critical systems in one transaction. AI-based scanners are getting better, but treat them as assistants, not final reviewers.

What Developers and Auditors Should Learn Next

If you work with DeFi smart contracts, flash loan attacks belong in your standard threat model. They are not an exotic edge case anymore. They are a normal tool in the attacker's kit.

For structured learning, Blockchain Council's Certified Smart Contract Developer™ gives readers deeper Solidity and contract security practice. If your focus is protocol design, look at the Certified DeFi Expert™, and security teams can pair this topic with Blockchain Council training in blockchain architecture and cybersecurity fundamentals.

Your next practical step: fork a DeFi protocol locally, write a flash loan style test that manipulates an AMM price, and see which assumptions break. If your contract stays safe when the attacker has massive temporary capital, you are designing for the DeFi environment that actually exists.