Reentrancy Attack

How It Works

A reentrancy attack exploits the order of operations in a vulnerable smart contract. The classic pattern involves a contract that sends ETH or tokens to a user before updating its internal balance records. When the attacker's contract receives the funds, its receive() or fallback() function automatically re-calls the vulnerable contract's withdraw function.

Because the vulnerable contract has not yet updated the attacker's balance (it sends funds first, then updates state), the contract still believes the attacker has their original balance. The withdraw function executes again, sending more funds, which triggers another re-entry — creating a recursive loop that drains the contract until it runs out of funds or gas.

Modern variants include cross-function reentrancy (entering through a different function than the one being exploited), cross-contract reentrancy (exploiting shared state between multiple contracts), and read-only reentrancy (manipulating view functions that other protocols depend on for pricing).

Why It Matters

The reentrancy attack is historically significant because it caused The DAO hack in 2016 — a $60 million exploit that led to the Ethereum hard fork creating Ethereum and Ethereum Classic. Despite being well-known for years, reentrancy vulnerabilities continue to appear in new contracts, often in more subtle forms that bypass basic protections.

The standard defense is the checks-effects-interactions pattern: check conditions first, update state variables (effects) second, and make external calls (interactions) last. Additionally, reentrancy guard modifiers (like OpenZeppelin's ReentrancyGuard) prevent a function from being called again while it is still executing.

Real-World Example

A lending protocol allows users to deposit ETH and withdraw their balance. The vulnerable withdraw() function sends ETH to the caller before setting their balance to zero. An attacker deposits 1 ETH, then calls withdraw(). When the contract sends the 1 ETH, the attacker's contract re-enters withdraw(). The balance still reads 1 ETH, so the contract sends another 1 ETH. This repeats until the protocol's entire ETH reserve is drained — all from a single 1 ETH deposit.