DEV Community: Abdelrahman ELsaheir

Anatomy of a Flash Loan Attack: Stealing Millions in One Transaction

Abdelrahman ELsaheir — Sun, 02 Nov 2025 23:44:44 +0000

In Web3, you can borrow $100 million with zero collateral.
And 15 seconds later, you can be walking away with a $2 million profit.

This isn't a "get rich quick" scheme; it's a Flash Loan Attack.

This is one of the most fascinating and feared exploits in DeFi. It’s not a "bug" in the traditional sense. It’s a feature, used as a weapon against a protocol's flawed economic logic. In this deep dive, we'll dissect exactly how these attacks work, look at the code, and understand how to defend against them.

Part 1: What is a Flash Loan? (The "Weapon")

Before it's an "attack," it's a "flash loan."

A flash loan is a feature offered by protocols like Aave and Uniswap. It allows you to borrow a massive amount of assets (e.g., $200M of ETH) with zero collateral.

The catch? You must repay the loan, plus a small fee, within the exact same transaction.

This is possible because of a core property of the blockchain called atomicity. A transaction is "atomic," meaning it either completes 100% (all steps succeed) or it fails and reverts 100% (as if it never happened).

So, for an attacker, a flash loan is a "risk-free" source of infinite capital.

If their attack succeeds: They repay the loan and keep the millions in profit.
If their attack fails: The entire transaction reverts, including the initial loan. They lose nothing (except gas fees).

Part 2: The Vulnerability (The "Weak Point")

A flash loan is just a tool. The real vulnerability is almost always Price Oracle Manipulation.

An oracle is how a smart contract asks, "What is the price of ETH right now?"

A bad protocol design is to get this price from a single, easily-manipulated source. The most common mistake? Using a single DEX liquidity pool (like a Uniswap V2 pool) as your price oracle.

Why is this a vulnerability? The price in a simple DEX pool is just a (Reserve A / Reserve B) formula. With enough capital (which a flash loan provides), an attacker can temporarily buy all of one asset, drastically skewing this price for one block.

Let's invent our vulnerable protocol:

PoorLenderBank.sol: A simple lending protocol.
It lets users deposit TokenA as collateral to borrow TokenB (which is a stablecoin).
The fatal flaw: To decide the value of TokenA, it checks the price directly from a single Uniswap V2 TokenA/TokenB pool.

Part 3: Anatomy of the Attack (Step-by-Step)
Here is the exact sequence of events, all happening inside one single transaction:

Deploy AttackContract.sol: The attacker first deploys their own smart contract.
Start the Attack: The attacker calls the startAttack() function on their contract.
Step 1: Get the Weapon (Flash Loan)
- The AttackContract requests a massive flash loan of, say, 10,000,000 TokenB (stablecoins) from Aave or Uniswap.
Step 2: Manipulate the Oracle
- The AttackContract takes all 10M TokenB and swaps them for TokenA on the vulnerable Uniswap pool that PoorLenderBank trusts.
- This single massive "buy" order drains the pool of TokenA and floods it with TokenB.
- The price of TokenA (relative to TokenB) on this pool skyrockets 1000x. (Reserve A / Reserve B) is now a huge number.
Step 3: Exploit the Vulnerable Protocol
- The AttackContract now goes to PoorLenderBank.sol.
- It deposits a tiny amount of TokenA (which it just bought) as collateral.
- PoorLenderBank checks the price of TokenA to see how much it's worth. It asks the manipulated Uniswap pool.
- The pool replies, "This TokenA is worth 1000x its normal value!"
- PoorLenderBank now believes the attacker's tiny TokenA deposit is "worth" millions.
- The attacker says, "Great. Based on my valuable collateral, I'd like to borrow all of your TokenB reserves."
- PoorLenderBank agrees and sends its entire treasury (e.g., 12,000,000 TokenB) to the AttackContract.
Step 4: Clean Up & Repay
- The AttackContract now has 12,000,000 TokenB.
- It only needs ~10,000,000 TokenB to repay its loan.
- It uses a portion of its stolen funds to swap back for TokenA (which restores the pool price, not that it matters).
- It repays the initial 10,000,000 TokenB flash loan + the small fee.
Step 5: Profit
- The attacker is left with ~2,000,000 TokenB (stablecoins) as pure profit.
- The transaction completes successfully. PoorLenderBank is left with worthless TokenA collateral and an empty treasury.

Part 4: The Code (Simplified)
This is what the logic looks like.

1. The Vulnerable Contract's Flaw (PoorLenderBank.sol)

// DO NOT USE THIS CODE. IT IS VULNERABLE.
import "@uniswap/v2-core/contracts/interfaces/IUniswapV2Pair.sol";

contract PoorLenderBank {
    IUniswapV2Pair public vulnerableOracle; // e.g., The ETH/USDC pool

    // ... other lending logic ...

    /**
     * THE FATAL FLAW:
     * This function gets the price from a single, manipulatable source.
     */
    function getCollateralValueInUSD(address _token, uint _amount) public view returns (uint) {
        // (reserves.reserve0, reserves.reserve1, ) = vulnerableOracle.getReserves();

        // This math is easily manipulated by a flash loan
        // uint price = reserves.reserve1 / reserves.reserve0; 

        // return _amount * price;
        // This will return a massively inflated value during an attack.
    }
}

2. The Attack Contract's Logic (AttackContract.sol)

This is a conceptual example of an attack contract using Aave's executeOperation callback.

import { ILendingPool, ILendingPoolAddressesProvider } from "@aave/protocol-v2/contracts/interfaces/ILendingPool.sol";

contract AttackContract {
    address public owner;
    ILendingPool public aavePool; // Aave V2 Lending Pool

    constructor(address _addressesProvider) {
        owner = msg.sender;
        aavePool = ILendingPool(ILendingPoolAddressesProvider(_addressesProvider).getLendingPool());
    }

    /**
     * This is the entry point for the attack.
     * 1. Takes the Flash Loan.
     * 2. Triggers the main attack logic in executeOperation().
     */
    function startAttack(address _loanAsset, uint _amount) external {
        // Request the flash loan from Aave
        aavePool.flashLoan(
            address(this),        // receiverAddress
            new address[] {_loanAsset},
            new uint[] {_amount},
            new uint[] {0},       // modes (0 for stable rate)
            address(this),        // onBehalfOf
            bytes(""),            // params
            0                     // referralCode
        );
    }

    /**
     * Aave calls this function *after* giving us the money.
     * This is where the step-by-step attack happens.
     */
    function executeOperation(
        address[] calldata assets,
        uint[] calldata amounts,
        uint[] calldata premiums,
        address initiator,
        bytes calldata params
    ) external returns (bool) {

        // Step 2: Manipulate the Oracle
        // ... code to swap(amounts[0]) on the vulnerable Uniswap pool ...

        // Step 3: Exploit the Vulnerable Protocol
        // ... code to deposit collateral and borrow from PoorLenderBank ...

        // Step 4: Clean Up & Repay
        // ... code to get back the original asset (if needed) ...

        uint amountToRepay = amounts[0] + premiums[0];
        // Ensure we have enough to repay Aave
        require(IERC20(assets[0]).balanceOf(address(this)) >= amountToRepay, "Failed to profit");

        // Approve Aave to take back the loan + fee
        IERC20(assets[0]).approve(address(aavePool), amountToRepay);

        return true; // Signal success
    }

    // Function to withdraw profits
    function withdraw() external {
        require(msg.sender == owner, "Not owner");
        // ... logic to send all remaining (stolen) tokens to owner ...
    }

    // We need a fallback to receive ETH if we borrow/steal it
    receive() external payable {}
}

Part 5: The Mitigation (The "Shield")

How do we stop this? NEVER trust a single, on-chain DEX pool for price data.

This is a solved problem.

Solution 1: Use Chainlink Price Feeds (The Standard)

Chainlink is a decentralized oracle network. It gathers price data from dozens of off-chain exchanges, aggregates it, and puts it on-chain in a way that cannot be manipulated by a single transaction.

// THE SECURE WAY
import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract SecureLenderBank {
    AggregatorV3Interface internal priceFeed;

    constructor() {
        // Set to the official ETH/USD feed.
        priceFeed = AggregatorV3Interface(0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419);
    }

    /**
     * THE FIX:
     * This function gets the price from a secure, decentralized oracle.
     * It is not vulnerable to flash loan manipulation.
     */
    function getCollateralValueInUSD() public view returns (int) {
        (
            , // roundId
            int price,
            , // startedAt
            , // updatedAt
            // answeredInRound
        ) = priceFeed.latestRoundData();

        // Returns a secure price, e.g., 3000 * 10**8
        return price;
    }
}

Solution 2: Use Time-Weighted Average Prices (TWAPs)

If you must get a price from a DEX, you can't use the "spot price." Instead, you must use a TWAP (Time-Weighted Average Price). Uniswap V2 and V3 have this feature built-in.

A TWAP calculates the average price over a period of time (e.g., the last 30 minutes). A flash loan attack happens in one block (12 seconds). It cannot influence the average price over 30 minutes, making it secure from this attack vector.

Conclusion
Flash loans are a powerful and neutral tool. They created an entire industry of "DeFi arbitrage." But in the hands of an attacker, they are the ultimate weapon for punishing lazy or naive protocol design.
For us as security professionals, the lesson is clear: Your protocol is only as secure as your price oracle. Never, ever, trust a single, manipulatable source for your data.
Disclaimer: All code provided is for educational, illustrative purposes only. It is simplified and not production-ready. Do not use the vulnerable code.

GMX V1 Exploit Analysis: How a $42M Classic Reentrancy Attack Unfolded

Abdelrahman ELsaheir — Sun, 02 Nov 2025 02:10:38 +0000

A Technical Post-Mortem on a Preventable Vulnerability

In the fast-paced world of Decentralized Finance (DeFi), protocols are built on a foundation of open-source code and immutable trust. But this code, no matter how innovative, is still written by humans. In July 2025, the Web3 community received a powerful reminder of this fact when GMX V1, one of the most popular perpetuals exchanges, was exploited in a sophisticated attack that drained $42 million from its vault.

The surprise? The vulnerability wasn't a novel zero-day attack. It was an old, well-documented adversary: Reentrancy.

In this technical deep dive, we will dissect the attack, identify the vulnerable code, explain how the attacker (later identified as a white-hat) exploited this flaw, and most importantly, discuss how it could have been prevented.

Quick Background: What is GMX V1?

To understand the hack, you must first understand the GMX model. It's a decentralized exchange that allows users to open leveraged long and short positions. Instead of a traditional order book, GMX uses a single liquidity pool model called GLP.

Users deposit assets (like ETH, WBTC) into the Vault contract and receive GLP tokens in return. This Vault acts as the counterparty to all traders; when traders win, the Vault (and GLP holders) lose, and vice-versa. Orders are executed by off-chain "Keepers" that call specific functions on the smart contract.

The Vulnerability: A Deep Dive

The flaw resided within the PositionManager contract, specifically in the executeDecreaseOrder function. This function is responsible for executing an order to close or reduce a user's position.

The flawed logic was as follows:

The contract calculates the collateral to be returned to the user.
The contract sends the collateral (in this case, ETH) back to the user.
After the transfer, the contract updates the protocol's internal state (like global position sizes, average entry prices, etc.).

This sequence is a critical violation of a core smart contract security principle.

The Vulnerable Code
Let's look at a simplified pseudo-code representation of the vulnerability within the PositionManager and its _transferOutETH helper function:

// Inside the PositionManager Contract
function executeDecreaseOrder(address _account, uint _sizeDelta, ...) {
    // ... (Various checks are performed)

    // Calculate collateral to be returned
    uint collateralAmount = ...; 

    // ... 

    // [!] THE VULNERABILITY IS HERE [!]
    // The contract sends ETH *before* updating its internal state.
    // This is an "Interaction" before an "Effect".
    _transferOutETH(_account, collateralAmount);

    // [!] STATE UPDATES HAPPEN *AFTER* THE EXTERNAL CALL [!]
    // These lines are supposed to run *after* the transfer
    _updateGlobalShorts(token, _sizeDelta); // Updates global position size
    _isLeverageEnabled[_account] = false;  // Resets leverage flag
    // ... (other state changes)
}

function _transferOutETH(address _receiver, uint _amount) internal {
    // ...
    // The .call{value: _amount}("") function transfers ETH.
    // If _receiver is a smart contract, this triggers its receive() or fallback() function.
    // This is the re-entrancy entry point.
    (bool success, ) = _receiver.call{value: _amount}("");
    require(success, "ETH transfer failed");
    // ...
}

As shown, _transferOutETH uses _receiver.call{value: _amount}.

When sending ETH to another smart contract, this function gives the receiving contract (the attacker's contract) the opportunity to execute its own code (via a receive() function) before the original executeDecreaseOrder function completes its execution.

The Attack: Step-by-Step

The attack was brilliant in its execution. Here is how it unfolded:

Step 1: The Setup
- The white-hat attacker deployed a malicious AttackContract.
- The attacker opened a small, legitimate short position on GMX.
Step 2: Triggering the Attack
- The attacker called executeDecreaseOrder from their AttackContract to close this small, legitimate position.
Step 3: The Entry Point
- The PositionManager contract began executing. It calculated the small collateral refund (an amount of ETH) and called _transferOutETH to send it to the attacker's address (the AttackContract).
Step 4: The Re-Entrancy
- As the AttackContract received the ETH, its receive() function was automatically triggered.
- This is the core of the attack: Inside this receive() function, the attacker's code called the Vault.increasePosition() function again, effectively "re-entering" the GMX protocol.
Step 5: The Exploit
- Because this new call happened before the original executeDecreaseOrder call could update the state (_updateGlobalShorts or _isLeverageEnabled), the protocol was in an "inconsistent state."
- The attacker was able to open a new, massive short position (with 30x leverage) while the protocol was still in a state that allowed it, and before the global price trackers were updated.
- This re-entrant loop was repeated, allowing the attacker to massively manipulate key state variables, particularly the globalShortAveragePrices.
Step 6: The Profit
- This manipulation artificially made the new, massive short positions appear deeply "unprofitable."
- According to GMX's logic, when short positions are losing, the Vault (and thus GLP holders) are "winning." This artifical, massive "profit" for the vault dramatically inflated the calculated Assets Under Management (AUM).
- An inflated AUM, in turn, artificially inflated the price of the GLP token.
- The attacker then simply redeemed their previously acquired GLP at this massively inflated price, walking away with a $42 million profit.

The Mitigation: How to Prevent This

This attack was 100% preventable by adhering to fundamental Solidity security patterns.

The Checks-Effects-Interactions (CEI) Pattern This is the golden rule of Solidity development:
- Checks: Perform all checks (e.g., require, if) first.
- Effects: Update all internal state variables (e.g., balances, flags) second.
- Interactions: Perform all external calls to other contracts (e.g., transferring funds) last. GMX should have updated _updateGlobalShorts and _isLeverageEnabled (the Effects) before calling _transferOutETH (the Interaction).

2. Use a Reentrancy Guard
The most direct and common fix is to use a simple modifier that "locks" a function, preventing it from being called again while it's already executing. The OpenZeppelin library provides a battle-tested solution.

The Fix: Corrected Code

Here is how the contract should have been written, applying both the ReentrancyGuard and the CEI pattern:

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

// Contract inherits from ReentrancyGuard
contract PositionManager is ReentrancyGuard {

    // Add the "nonReentrant" modifier to the function
    function executeDecreaseOrder(...) external nonReentrant {

        // [FIXED] 1. Checks
        // ... (All require() statements)

        // [FIXED] 2. Effects
        // State updates now happen *before* the external call
        _updateGlobalShorts(token, _sizeDelta);
        _isLeverageEnabled[_account] = false;

        // ... (other calculations)
        uint collateralAmount = ...;

        // [FIXED] 3. Interaction
        // External call is the *last* step in the function
        _transferOutETH(_account, collateralAmount); 
    }

    // ...
}

The nonReentrant modifier alone would have stopped this specific attack vector, but adhering to the CEI pattern is the more robust and correct architectural solution.

Conclusion & Key Takeaways for Developers

The GMX V1 incident is a powerful lesson that trust in Web3 is not just about the blockchain; it's about the quality of the code running on it.

Never Trust External Calls: Always assume that any contract you call (receiver.call) is malicious and will try to re-enter your functions.
Master the CEI Pattern: The "Checks-Effects-Interactions" pattern must be the first law of your Solidity development process.
Use Secure Libraries: Don't reinvent the wheel. Use battle-tested libraries like OpenZeppelin for ReentrancyGuard and SafeMath.
Audit Every Change: This vulnerability was reportedly introduced in a fix for a separate, earlier bug, and that fix was not sufficiently audited. Every single line of code pushed to production, no matter how small, must undergo a rigorous security review.

For us as Web3 security professionals, these incidents are invaluable case studies. Understanding them at a code level is what separates an expert from an amateur.

References
For further technical reading and verification of this incident:

CertiK: GMX Incident Analysis (July 2025)
Halborn: Explained: The GMX Hack (July 2025)