A reentrancy attack exploits a specific vulnerability in smart contract execution: when a contract sends ETH to an external address and that address is a contract with a receive() or fallback() function, the receiving contract can call back into the sender before the sender has updated its internal state. If the vulnerable contract checks a user’s balance, then sends ETH, then updates the balance — an attacker can re-enter during the ETH send step, pass the balance check again (it hasn’t been deducted yet), and drain funds repeatedly until the contract is empty. This “checks-send-effects” ordering error is one of the most historically damaging smart contract vulnerabilities. The DAO Hack (June 2016) used reentrancy to drain 3.6M ETH (then ~$60M; worth billions today) from The DAO smart contract, directly causing the Ethereum hard fork that created ETH and ETC. Despite being one of the oldest known Solidity vulnerabilities, reentrancy attacks continued causing losses in 2020-2024 DeFi protocols.
How It Works
Vulnerable pattern:
“`
function withdraw(uint amount) external {
require(balances[msg.sender] >= amount); // CHECK
(bool ok,) = msg.sender.call{value: amount}(“”); // INTERACT (ETH send)
balances[msg.sender] -= amount; // EFFECTS (too late — already reentered)
}
“`
Attack pattern:
“`
// Attacker’s contract fallback:
receive() external payable {
if (target.balance >= 1 ether) {
target.withdraw(1 ether); // re-enter before state updated
}
}
“`
Execution flow: Attacker calls withdraw(1 ether) → balance check passes → ETH sent to attacker contract → attacker’s receive() fires → re-calls withdraw(1 ether) before first call’s state update → balance check passes again → ETH sent again… loops until contract is empty.
Fix: Checks-Effects-Interactions pattern:
“`
function withdraw(uint amount) external {
require(balances[msg.sender] >= amount); // CHECK
balances[msg.sender] -= amount; // EFFECTS (update state first)
(bool ok,) = msg.sender.call{value: amount}(“”); // INTERACT (now safe)
}
“`
Key Variants
| Variant | Description |
|---|---|
| Single-function reentrancy | Classic re-entry into the same function |
| Cross-function reentrancy | Re-enters a different function sharing state |
| Cross-contract reentrancy | Multiple contracts share state; re-entry targets different contract |
| Read-only reentrancy | Re-enters during a read operation to exploit integration that trusts stale state |
History
- 2016 (June): The DAO Hack — 3.6M ETH drained via reentrancy; largest crypto exploit at the time; directly caused Ethereum hard fork (ETH/ETC split)
- 2020: Multiple DeFi protocols exploited via reentrancy despite DAO awareness — developer education failed to propagate
- 2022: Read-only reentrancy attacks emerge — exploiting protocols that integrate with Curve/other DeFi reading stale pool state during reentrant execution
- 2023: Continued reentrancy losses in cross-contract and cross-protocol scenarios despite ReentrancyGuard availability in OpenZeppelin
Common Misconceptions
“Reentrancy only affects ETH transfers, not ERC-20.”
Cross-function reentrancy and read-only reentrancy can affect ERC-20 operations too — any external call can trigger reentrancy, including token transfers to contracts with hooks (ERC-777 tokens have transfer hooks that have enabled reentrancy attacks on protocols accepting ERC-777).
“Using ReentrancyGuard solves all reentrancy risks.”
OpenZeppelin’s ReentrancyGuard (mutex lock) prevents single-function reentrancy within one contract but does not prevent cross-contract reentrancy where state is shared across multiple contracts — protocols must analyze their entire interaction graph. Read-only reentrancy bypasses function-level guards entirely.
Criticisms
- Historic failure to learn: Despite The DAO hack in 2016 making reentrancy famous, the pattern continued appearing in audited protocols for years — developer education, tool detection, and code review processes repeatedly failed to prevent well-known vulnerabilities
- Read-only reentrancy underappreciated: The newer read-only reentrancy variant has caused significant losses post-2022 while receiving less attention in tutorials and tooling than classic reentrancy
Social Media Sentiment
Reentrancy discussions spike after each new exploit. The DAO hack remains legendary in Ethereum history — any major reentrancy incident triggers references to “we should have learned from The DAO.” Overall: well-understood in developer community; remains embarrassingly prevalent in production code; constant reminder that smart contract security requires defense in depth.
Last updated: 2026-04
Related Terms
Sources
- “The DAO Hack: Technical Post-Mortem” — Ethereum Foundation / Christoph Jentzsch (2016). Original analysis of the DAO reentrancy exploit — detailed explanation of the vulnerable splitDAO function, how the attacker exploited recursive call, and the amount drained.
- “Reentrancy Vulnerabilities in Smart Contracts: A Systematic Study” — IEEE / ACM Papers (2020-2022). Academic systematic analysis of reentrancy vulnerability patterns — classifying variants (same-function, cross-function, cross-contract, read-only), prevalence in deployed contracts, and detection tool effectiveness.
- “Curve Finance Read-Only Reentrancy: Technical Analysis” — BlockSec / Chainalysis (2022-2023). Analysis of the read-only reentrancy vector leveraging Curve Finance pool state — explaining how protocols integrating with Curve could be manipulated by reading stale pool balances during reentrant execution.
- “Detecting Reentrancy in Production Code: Slither, Mythril, and Manticore” — Trail of Bits (2021-2023). Comparative evaluation of automated reentrancy detection tools — testing against known vulnerable and patched contracts, evaluating false positive/negative rates, and identifying gaps in tool coverage.
- “ERC-777 Reentrancy Attacks: When Token Hooks Enable Exploits” — OpenZeppelin Research (2020-2022). Analysis of how ERC-777’s transfer hooks (tokensReceived/tokensToSend) enabled reentrancy attacks on protocols accepting ERC-777 tokens — documenting real losses in Uniswap v1, dForce, and other protocols.