What Is a Reentrancy Attack?
Reentrancy is a smart contract vulnerability in which a contract can be called again before it finishes updating its own records. Attackers use it to withdraw the same funds repeatedly in a single transaction.
On this page 6
Reentrancy is a smart contract vulnerability in which a contract can be called again, or “re-entered”, before it has finished updating its own records. An attacker can use that gap to withdraw the same funds over and over within a single transaction. The 2016 attack on The DAO, one of the most famous incidents in Ethereum’s history, was a reentrancy exploit.
How does a reentrancy attack work?
On Ethereum, when a smart contract sends ETH to an address that is itself a contract, the receiving contract’s code can run. Reentrancy happens when the sending contract hasn’t yet updated its state at that moment. In a simple withdrawal scenario:
- The attacker deposits 1 ETH into the target contract and requests a withdrawal.
- The target checks the balance and sends 1 ETH to the attacker’s contract.
- As soon as the ETH arrives, the attacker’s contract automatically calls the withdraw function again.
- The target hasn’t zeroed the attacker’s balance yet, so it approves a second withdrawal.
- The loop continues until the contract runs dry or the transaction hits its limits.
The root cause is ordering: the contract sends money first and updates the balance afterwards, leaving a window open in between.
The DAO hack
The DAO was a decentralized investment fund launched on Ethereum in 2016 that raised a large amount of ETH through a crowdsale. In June 2016, an attacker used a reentrancy bug to move roughly 3.6 million ETH into a child contract under their control. The Ethereum community chose to reverse the theft with a hard fork, and the chain that rejected that decision carried on as Ethereum Classic.
Types of reentrancy
- Single-function: The attacker calls the same function repeatedly, as in The DAO.
- Cross-function: The attacker re-enters through a different function that shares the same state.
- Cross-contract: Several contracts share state, and the bug lies in how they interact.
- Read-only: Another protocol reads the stale state mid-transaction and calculates a wrong price.
The flaw doesn’t always sit in application code. In July 2023, a bug in certain older versions of the Vyper compiler broke reentrancy locks, and several Curve pools were drained as a result.
How is reentrancy prevented?
Developers rely on a few standard defenses:
- Checks-Effects-Interactions: Check conditions first, update state such as balances next, and make external calls last.
- Reentrancy guards: A lock that blocks a function from being entered again while it is running; OpenZeppelin’s ReentrancyGuard is the best-known example.
- Audits and testing: Reviewers look specifically at how functions and contracts interact.
For users, a “reentrancy-protected” label is not a security guarantee on its own. Checking which code version an audit covered and not concentrating large sums in one protocol are more meaningful precautions. Our exploit entry covers the wider picture.
Frequently asked questions
Does reentrancy only happen on Ethereum?
It is most common on Ethereum and EVM-compatible chains, where contracts can freely call one another. Similar issues can appear on any platform that allows contract-to-contract calls.
Will disconnecting my wallet protect me?
No. A reentrancy bug affects the pooled funds the protocol holds, and anything you have deposited stays inside the contract.