Flash loan attacks have emerged as one of the most devastating attack vectors in decentralized finance, with February 2023 recording a staggering 22 incidents and $15.9 million in losses — the highest monthly total since 2021, according to CertiK’s monthly security report. As the DeFi ecosystem grows with Ethereum at $1,643 and the total market cap of DeFi protocols exceeding $50 billion, understanding how flash loan attacks work at a technical level is essential for developers, auditors, and advanced users who want to protect their protocols and investments.
The Objective
This tutorial provides a comprehensive technical walkthrough of flash loan attack mechanics. By understanding how these attacks are constructed, you will be able to identify vulnerabilities in smart contract code, implement effective defenses, and evaluate the security posture of DeFi protocols before committing funds. This is not a guide for executing attacks — it is a guide for preventing them.
Prerequisites
To follow this walkthrough effectively, you should have a working understanding of Solidity smart contracts, decentralized exchange mechanics including automated market makers, and basic familiarity with Ethereum transaction structure. Knowledge of price oracle systems and liquidity pool mathematics will be helpful for understanding the attack vectors discussed.
You need access to an Ethereum testnet such as Sepolia or Goerli, a development environment like Hardhat or Foundry, and a block explorer for verifying transaction details. All code examples use Solidity 0.8.x syntax and are designed for educational purposes on test networks only.
Step-by-Step Walkthrough
Step 1: Understanding Flash Loans. A flash loan is an uncollateralized loan that must be borrowed and repaid within a single atomic transaction. Protocols like Aave and dYdX offer flash loans, allowing anyone to access millions of dollars in liquidity temporarily. The atomic nature of Ethereum transactions means that if the loan is not repaid by the end of the transaction, the entire transaction reverts — no funds are lost by the lending protocol.
The legitimate use cases for flash loans include arbitrage between exchanges, collateral swaps, and self-liquidation of undercollateralized positions. However, the same mechanism that enables these useful functions also enables attacks.
Step 2: The Attack Architecture. A flash loan attack typically follows this pattern. First, the attacker borrows a large amount of a token through a flash loan. Second, they use this capital to manipulate the price of a target token on a decentralized exchange, often by creating a massive sell or buy order that distorts the price oracle. Third, they exploit this manipulated price on a separate protocol that relies on the oracle for pricing. Fourth, they repay the flash loan and pocket the profit.
Consider a simplified example. An attacker borrows 10,000 ETH through a flash loan from Aave. They then use this ETH to buy a large quantity of Token X on Uniswap, driving up its price. A separate lending protocol that uses Uniswap as a price oracle now sees Token X as significantly more valuable. The attacker deposits a relatively small amount of Token X as collateral in the lending protocol and borrows a disproportionate amount of ETH against it, based on the inflated price. Finally, the attacker repays the flash loan and is left with a profit — the excess ETH borrowed against the artificially inflated collateral.
Step 3: Identifying Vulnerable Code Patterns. The most common vulnerability is single-source oracle dependency. If a protocol reads its price from only one decentralized exchange, that price can be manipulated. The vulnerable code pattern looks like this: a function that queries a DEX reserves ratio directly without time-weighted averaging.
Another common vulnerability is insufficient reentrancy protection. Flash loan attacks often exploit reentrancy by calling back into a vulnerable contract during the execution of a function, before state variables have been updated. While the Checks-Effects-Interactions pattern and reentrancy guards mitigate this, some complex DeFi interactions create subtle reentrancy opportunities that basic guards miss.
Step 4: Implementing Defenses. The most effective defense against flash loan attacks is using time-weighted average price oracles, such as Uniswap V2’s TWAP or Uniswap V3’s built-in oracle. These oracles average prices over a time period, making it impossible for an attacker to manipulate the price within a single transaction.
For custom oracle implementations, use a median price from multiple sources, implement circuit breakers that halt operations when prices move beyond expected ranges, and add delay mechanisms for large withdrawals. Protocol-level defenses should include flash loan detection — monitoring for transactions that interact with known flash loan providers — and adjusting collateral ratios or pausing operations when such activity is detected.
Step 5: Testing and Verification. After implementing defenses, test them using flash loan attack simulations on testnets. Create attack contracts that attempt to exploit your protocol using flash loans, and verify that your defenses prevent price manipulation and unauthorized withdrawals. Use fuzzing tools like Echidna or Foundry’s built-in fuzzer to discover edge cases in your price oracle implementation.
Troubleshooting
If your oracle returns stale prices during periods of high volatility, consider implementing a freshness check that rejects prices older than a configurable threshold. If your protocol is vulnerable to sandwich attacks around large trades, consider implementing commit-reveal schemes or batch auction mechanisms. If gas costs for multi-source oracle queries are too high, optimize by caching prices on-chain and updating only at defined intervals.
Common implementation mistakes include using spot prices instead of TWAPs, forgetting to handle edge cases where liquidity is removed from a pool, and not accounting for flash loan fees in the attack profitability calculation. Each of these can leave subtle vulnerabilities that are exploitable under the right market conditions.
Mastering the Skill
Flash loan attack prevention is an ongoing discipline. Stay current with new attack vectors by following security researchers and audit firms on social media. The record 22 flash loan attacks in February 2023 demonstrate that attackers continue to innovate, finding new combinations of protocols to exploit. Study each incident report in detail, understand the specific vulnerability that was exploited, and evaluate whether your own protocols have similar exposure.
Consider contributing to open-source security tools and audit frameworks. The DeFi security community thrives on shared knowledge, and the most effective defenses are built collaboratively. Regular security audits from reputable firms, combined with bug bounty programs, provide the strongest protection against flash loan attacks and other exploit vectors.
Disclaimer: This article is for educational and informational purposes only. It does not constitute financial or security advice. Always conduct professional security audits before deploying smart contracts.
flash loans for 50K can drain a pool worth millions because devs keep using spot price oracles. the attack toolkits being under 1 ETH just lowered the barrier to entry
Anouk V. 15.9M in one month and protocols still ship without TWAP. CertiK found 22 incidents and thats just the reported ones. small teams that got hit for 200K just go quiet
22 flash loan attacks in february alone and $15.9M gone. certik counted every single one and protocols still werent reading their own reports
22 flash loan attacks in one month and teams still deploy with a single chainlink oracle. nothing changed since feb 2023
22 attacks in february 2023 and teams still deploy with single oracles in 2026. the CertiK numbers were a warning nobody listened to
the reentrancy patterns shown here are exactly what Euler ignored a year later. $197M gone because nobody reads post-mortems
Janne K. Euler was the painful proof. everyone shares this article after the fact but protocols keep repeating identical mistakes
22 flash loan incidents in february 2023 alone and $15.9m gone. and that was before the real deFi summer kicked off. wonder what 2026 numbers look like
buff_satoshi asking about 2026 numbers is painful. flash loan attacks are still happening weekly. auditors cant keep up with copy pasta exploit kits
the technical breakdown of oracle manipulation here is solid. most devs still dont understand that using a single price feed is basically asking to get exploited
^ flashloan as a service toolkits on dark forums for under 1 eth now. barrier to entry for attacking is dropping fast
flashloan attack toolkits for under 1 eth on dark forums. the barrier to exploitation is collapsing while audit costs keep rising. something has to give
the CertiK numbers are probably undercounting too. plenty of smaller protocols that got hit for 50-100k never even reported because the reputational damage was worse than the loss
dimitri the toolkits being under 1 eth is the scary part. a 14 year old with a metamask wallet can drain an un audited protocol now
flashloan toolkits for under 1 eth is the part that keeps me up. script kiddies can copy paste an attack now. the barrier is basically zero
0xphantom the toolkits being under 1 eth is terrifying. you can rent a flash loan attack for less than a nice dinner now. the asymmetry favors attackers completely
Mirela V. the attack toolkits being under 1 ETH is the part that keeps me up. you can rent a flash loan attack for less than a Ledger Nano costs. the economics completely favor attackers
Yuki T nailed it. single price feed exploitation accounts for like 60% of flash loan attacks and teams still deploy with one chainlink oracle and call it safe
oracle_sux 60% from single price feed exploitation is wild. Chainlink TWAP is free and takes 10 lines of code but teams still skip it to save gas
twap_or_bust_ chainlink TWAP is free but devs still use spot price from uniswap v3 pools because integration is easier. 22 attacks in february proves laziness beats security every time
the reentrancy_ghost point about devs picking spot price over TWAP because integration is easier is the whole problem. 10 lines of Chainlink code vs saving 5000 gas. the ROI on that laziness is brutal
twap_or_bust_ saying chainlink twap takes 10 lines of code is generous. integrating it properly with your specific AMM curves is like 200 lines and most teams just copy paste the docs example without adjusting
the section on reentrancy guards and twap oracles should be required reading before anyone deploys a defi protocol. seriously
the reentrancy guard section should be printed and taped to every solidity developer’s monitor. such a basic fix that still gets skipped
22 flash loan attacks in one month and protocols still use single-price oracles. certik counted $15.9M gone and the same patterns keep repeating
oracle_gap_ the issue is devs treat audits as a checkbox. if your protocol uses AMM spot prices as oracle inputs youve already lost