A reentrancy attack is an exploit against smart contracts in which a malicious contract calls back into the victim contract before the victim has finished its first execution, typically before it updates balances or other state. Because the victim still sees the old state, the attacker can repeat an action such as a withdrawal many times within a single transaction.
Reentrancy is one of the oldest and most expensive classes of vulnerability in EVM-based smart contracts. It led to the loss of millions of ether from The DAO in 2016 and the resulting Ethereum hard fork, and variants still appear in audits today because external calls hand control to untrusted code.
How a reentrancy attack works
On the Ethereum Virtual Machine, sending ether or calling another contract transfers execution control to that contract. If the recipient is a contract, its receive or fallback function runs automatically, and it can call the original contract again while the first call is still on the stack.
The classic vulnerable pattern is a withdraw function that sends funds first and sets the balance to zero afterwards. The attacker deposits a small amount, calls withdraw, and in its fallback function calls withdraw again. Each nested call passes the balance check because the state update has not happened yet, so the loop continues until the contract is empty or the gas runs out.
The sequence below shows a single-function attack step by step.
| Step | Victim contract | Attacker contract |
|---|---|---|
| 1 | Records a deposit of 1 ETH | Deposits 1 ETH |
| 2 | Checks balance, sends 1 ETH | Calls withdraw |
| 3 | Balance still shows 1 ETH | Fallback re-enters withdraw |
| 4 | Sends another 1 ETH | Repeats until funds are gone |
| 5 | Sets balance to zero too late | Keeps the drained ether |
Types of reentrancy
Reentrancy is broader than one function calling itself. Modern exploits often re-enter through a different function or even a different contract that shares state with the victim.
| Variant | How the attacker re-enters | Typical target |
|---|---|---|
| Single-function | Calls the same function again | Simple withdraw logic |
| Cross-function | Calls another function sharing the same state | Transfer and withdraw pairs |
| Cross-contract | Uses a second contract reading stale shared state | Multi-contract protocols |
| Read-only reentrancy | Calls a view function during an inconsistent state | Price oracles and lending markets |
| Token hook reentrancy | Uses callbacks in token standards | Contracts accepting ERC-777 or NFT transfers |
Read-only reentrancy is especially subtle. The attacked contract itself may lose nothing, but another protocol reads a temporarily wrong price or balance from it mid-transaction and makes a bad lending or liquidation decision. Token standards that call the recipient, such as ERC-777 hooks or the onERC721Received callback, create hidden external calls that developers often overlook.
Defenses and secure coding patterns
The primary defense is the checks-effects-interactions pattern: first validate inputs, then update all internal state, and only then make external calls. If the balance is set to zero before the ether leaves, a nested call finds nothing to withdraw.
A second layer is a reentrancy guard, a mutex flag that makes a function revert if it is entered again before it finishes. Widely used libraries such as OpenZeppelin provide a nonReentrant modifier, and since the Cancun upgrade transient storage allows cheaper guards that reset automatically at the end of the transaction.
| Defense | What it prevents | Limitation |
|---|---|---|
| Checks-effects-interactions | Stale state during external calls | Hard to apply across many contracts |
| Reentrancy guard | Re-entering protected functions | Does not cover view functions or other contracts |
| Pull payments | Push-style transfers inside loops | Users must claim funds themselves |
| Gas-limited transfers | Complex fallback logic | No longer reliable after gas cost changes |
| Formal verification | Whole classes of state violations | Costly and needs precise specifications |
Relying on the 2,300 gas stipend of transfer and send was once common advice. It is now discouraged because gas costs of opcodes have changed in network upgrades, which can break legitimate recipients and gives no guarantee of safety in the future.
Reentrancy compared with related smart contract risks
Reentrancy is a logic flaw inside one transaction, which distinguishes it from attacks that exploit transaction ordering or external data.
| Risk | Root cause | Main mitigation |
|---|---|---|
| Reentrancy attack | External call before state update | Checks-effects-interactions and guards |
| Front-running and MEV | Visible pending transactions | Private order flow, commit-reveal |
| Oracle manipulation | Price from a thin or spot source | Time-weighted or decentralized oracles |
| Access control flaw | Missing permission checks | Role management and audits |
In practice these risks combine. Attackers often use flash loans to fund a reentrancy exploit or pair read-only reentrancy with oracle manipulation, so a smart contract audit evaluates them together rather than one by one.
Detection, testing and common mistakes
Static analysis tools flag state writes after external calls, and fuzzing frameworks such as those integrated with Hardhat or Foundry simulate malicious callers. Even so, many incidents involve code that passed automated checks, because the vulnerable path crosses contracts or depends on unusual tokens.
- Guarding only one function while a sibling function updates the same state unprotected.
- Trusting view functions of external protocols during a transaction that is still in progress.
- Ignoring token callbacks when integrating NFT or hook-enabled token standards.
- Trusting compiler-provided locks without testing; a 2023 bug in certain Vyper versions broke reentrancy locks and caused large losses.
A plain-language summary
Picture a cash machine that pays out before it updates the account. A clever thief presses the button again and again. Each press lands before the balance changes. The thief leaves with far more than was ever deposited.
Smart contracts can fail in the same way. The fix is easy to state: update the records first, pay out last. Then lock the door so nobody can come back in until the first request is done.
An example from practice
A team building a small lending protocol prepares for launch. During the smart contract audit, a reviewer notices that the withdrawCollateral function sends ether to the user and reduces the stored collateral afterwards. A separate function, borrow, reads the same collateral value without a guard.
The auditor writes a test in which an attacker contract withdraws collateral and, from its fallback function, calls borrow against the collateral that has not yet been reduced. In the test environment, an attacker with 10 ETH of collateral walks away with the collateral plus a loan of about 7 ETH that is no longer backed.
The team reorders the logic to follow checks-effects-interactions, adds a shared reentrancy guard to both functions and repeats the test. The exploit now reverts, and the issue is fixed before any user funds are at risk.