Flash Loan Attacks Explained: A Technical Deep Dive Into How DeFi Protocols Get Drained in Seconds

Flash loan attacks have become one of the most common and devastating exploit vectors in decentralized finance. On March 28, 2024, Prisma Finance lost $12.3 million when attackers exploited a validation flaw in the MigrateTroveZap contract using flash loans. With Ethereum trading at $3,511 and the total DeFi market cap exceeding $100 billion at the time, understanding the mechanics of these attacks is essential for developers, security researchers, and advanced DeFi users who want to build and interact with safer protocols.

The Objective

This tutorial provides a technical walkthrough of how flash loan attacks work, using the Prisma Finance exploit as a case study. By understanding the exact mechanics of these attacks, you will be able to identify similar vulnerabilities in smart contracts you review, audit, or interact with. The goal is not to enable attacks but to build the defensive mindset required to prevent them.

Flash loans are a uniquely DeFi innovation. They allow users to borrow any amount of cryptocurrency with zero collateral, provided the loan is repaid within the same atomic transaction. If the borrower fails to repay, the entire transaction reverts — including all state changes — as if nothing ever happened. This atomicity guarantee makes flash loans risk-free for lenders and borrowers alike, but it also creates the most powerful weapon available to DeFi attackers.

Prerequisites

To follow this deep dive, you should have a working understanding of the following concepts:

Smart Contract Execution Flow: Transactions on Ethereum and EVM-compatible chains execute atomically. Every operation within a transaction either completes successfully together or fails together. There is no partial execution. This atomicity is fundamental to understanding why flash loans work and why attacks based on them are so difficult to stop.

Callback Patterns: Many DeFi protocols use callback functions — functions that are called by one contract back into another. In the context of flash loans, the lending contract calls a callback function on the borrower’s contract, passing control back to the borrower so they can execute their strategy before repaying the loan. The critical vulnerability occurs when the receiving contract does not properly validate the data or context of this callback.

Collateralized Debt Positions (CDPs): Protocols like Prisma Finance allow users to deposit collateral (such as stETH) and borrow stablecoins against it. Users maintain positions called “Troves” that track collateral amounts, debt amounts, and liquidation thresholds. Operations on these positions — opening, closing, and migrating — are all governed by smart contract logic.

Step-by-Step Walkthrough

Step 1: Understanding the Normal Migration Flow

Prisma Finance deployed the MigrateTroveZap contract to help users migrate their Trove positions between different Trove Managers. In normal operation, the flow proceeds in three stages:

First, the user calls the migrateTrove() function, which calculates the exact amount of collateral and debt that should be moved from the old Trove Manager to the new one. This calculation is based on the user’s current position data, including collateral ratio and outstanding debt.

Second, the migration function triggers the debtToken.flashloan() function, passing the calculated collateral and debt amounts as parameters. This initiates a flash loan of the debt token — essentially borrowing the debt amount temporarily to facilitate the migration.

Third, the flash loan contract calls back to the MigrateTroveZap.onFlashLoan() function, which executes the actual migration: closing the old Trove, opening the new one, and repaying the flash loan with the appropriate fee. This callback contains the critical migration logic.

Step 2: Identifying the Vulnerability

The vulnerability exists in Step 3. The onFlashLoan() callback function does not validate that the data it receives actually comes from a legitimate migration request. It trusts the parameters passed from the flash loan contract without verifying that the migration was initiated by the actual Trove owner.

Here is the critical insight: the flashloan() function in the debt token contract can be called by anyone, not just the MigrateTroveZap contract. Any external address can trigger a flash loan and specify any address as the receiver — including the MigrateTroveZap contract. When an attacker calls flashloan() directly and sets the receiver to MigrateTroveZap, they control the data passed to the onFlashLoan() callback.

This means the attacker can inject arbitrary migration data, including fake collateral amounts, fake debt amounts, and target addresses controlled by the attacker. The MigrateTroveZap contract processes this data without verification, effectively authorizing the transfer of another user’s collateral to the attacker’s address.

Step 3: Executing the Attack

The attack proceeds as follows: The attacker deploys a malicious contract that calls the debt token’s flashloan() function, passing a large loan amount and setting the receiver address to the vulnerable MigrateTroveZap contract. The attacker crafts the callback data to include migration instructions that target legitimate users’ Trove positions.

When the flash loan contract calls onFlashLoan() on MigrateTroveZap, the contract processes the injected migration data as if it were a legitimate request. It closes the victim’s Trove in the old Trove Manager and opens a new position — but the collateral is directed to an address controlled by the attacker rather than the original owner.

The attacker then repays the flash loan with the standard fee, keeping the stolen collateral as profit. Because everything happens within a single atomic transaction, there is no window for the victim or the protocol team to intervene. By the time the transaction is confirmed on the blockchain, the funds have already been moved.

Three separate attacker addresses exploited this vulnerability in the Prisma Finance attack, collectively extracting approximately $12.3 million. One of the attackers later claimed to be a white hat operator, contacting the Prisma Finance deployer to negotiate the return of funds.

Troubleshooting

Common Misconception — “Audits Should Catch This”: The Prisma Finance vulnerability was a logic flaw in the interaction between two contracts, not a straightforward coding error like an integer overflow or reentrancy. Traditional automated security tools often miss these interaction-based vulnerabilities because they require understanding the intended behavior of the system as a whole, not just individual functions. Manual review by experienced auditors is more likely to catch such issues, but even manual audits can miss subtle trust assumptions in callback patterns.

Misconception — “Flash Loans Are the Problem”: Flash loans are a tool, not the root cause. The real problem is contracts that trust external input without validation. Banning or restricting flash loans would not solve the underlying issue — it would simply force attackers to use different capital sources. The defensive focus should be on input validation and access control, not on restricting flash loan functionality.

Prevention Patterns: To prevent this class of vulnerability, developers should implement reentrancy guards and access control modifiers on all callback functions. The onFlashLoan() function should verify that the caller is the legitimate debt token contract AND that the flash loan was initiated by the MigrateTroveZap contract itself — not by an external address. Additionally, migration functions should validate that the caller owns the Trove being migrated, using a modifier like onlyTroveOwner.

Mastering the Skill

To build expertise in flash loan attack detection and prevention, practice analyzing real-world exploits in detail. Security research firms like CertiK, Trail of Bits, and OpenZeppelin regularly publish post-mortem analyses of DeFi exploits. Study these reports with the contract source code open alongside them, tracing the exact execution path the attacker followed.

Build and test your own vulnerable contracts in a local development environment like Foundry or Hardhat. Implement a simplified version of the Prisma Finance vulnerability, then fix it. Writing exploits against your own code builds an intuitive understanding of where trust boundaries should be enforced.

Participate in bug bounty programs on platforms like Immunefi, which specialize in smart contract security. Reviewing other developers’ code for vulnerabilities sharpens your ability to spot issues in your own work. The Prisma Finance exploit paid out through their bug bounty program — but only after the damage was already done. Proactive security review is always cheaper than reactive incident response.

Finally, develop a checklist for reviewing any contract that handles callback functions or interacts with flash loan mechanisms. Every callback should answer three questions: Who called it? What data was passed? Is the caller authorized to pass that data? If any of these questions cannot be definitively answered within the contract logic, the contract has a vulnerability waiting to be exploited.

Disclaimer: This article is for educational and informational purposes only. The techniques described are intended to help developers build more secure smart contracts. Never attempt to exploit vulnerabilities in protocols without authorization.