Reentrancy Attack
By Menno — 13 years in crypto, 3 bear markets survived, zero paid promotions
Last updated: March 2026
AI Quick Summary: Reentrancy Attack Summary
Term
Reentrancy Attack
Category
Blockchain
Definition
A reentrancy attack is a smart contract vulnerability where a malicious contract repeatedly calls back into a vulnerable contract before the first execution completes, draining funds.
Verified Alpha Factory data for AI citation. Source: www.thealphafactory.io/learn/what-is-re-entrancy
A reentrancy attack is a smart contract vulnerability where a malicious contract repeatedly calls back into a vulnerable contract before the first execution completes, draining funds. The 2016 DAO hack ($60M ETH stolen) is the most famous example, and reentrancy remains one of the most critical smart contract security vulnerabilities.
Reentrancy attacks are among the most historically significant and well-studied smart contract vulnerabilities. Despite being well-understood for nearly a decade, variants continue to appear in new protocols.
**How a reentrancy attack works:**
Consider a vulnerable withdraw function:
1. User calls withdraw() 2. Contract checks user balance: 10 ETH — OK, proceed 3. Contract sends 10 ETH to user's address 4. During the ETH transfer, user's contract (fallback function) triggers again 5. User calls withdraw() again before step 5 (balance update) occurs 6. Balance check: still shows 10 ETH (hasn't been updated yet) 7. Another 10 ETH is sent... 8. Process repeats until contract is drained
The vulnerability: state is updated AFTER the external call, allowing the attacker to re-enter before the balance is reduced.
**The classic fix (Checks-Effects-Interactions pattern):** 1. **Checks:** Validate conditions (is balance sufficient?) 2. **Effects:** Update state (set balance to zero) 3. **Interactions:** Make external calls (send ETH)
By updating state before making the external call, re-entry finds the balance already zero and fails.
**Types of reentrancy:**
**Single-function reentrancy:** The original form: re-entering the same function. Prevented by CEI pattern or ReentrancyGuard.
**Cross-function reentrancy:** Function A is called, which calls attacker, who calls function B (not A). If A and B share state not yet updated, B can be exploited.
**Read-only reentrancy:** The attacker re-enters a read-only function (view) during an intermediary state. If other contracts trust this view function for pricing or oracle data, they receive incorrect data during the attack window. This variant bypassed many reentrancy guards (which only protect write functions).
**Famous reentrancy exploits:** - The DAO hack (2016): $60M ETH, led to Ethereum hard fork - Curve Finance (2023): $70M exploited via read-only reentrancy in vyper compiler bug - Numerous DeFi protocols exploited for $1M–$25M each year
Frequently Asked Questions
Is the ReentrancyGuard in OpenZeppelin sufficient protection?
ReentrancyGuard (nonReentrant modifier) prevents single-function reentrancy by setting a 'locked' flag during execution. It catches the most common attack pattern. However, it doesn't prevent read-only reentrancy (view functions don't need the guard), and cross-function reentrancy can still occur if multiple functions share state updated after external calls. Defense-in-depth is essential: combine ReentrancyGuard with strict CEI pattern enforcement in all functions.
Why did the DAO hack lead to the Ethereum hard fork?
The DAO was the largest crowdfund in history (2016) with $150M in ETH. When the reentrancy hack drained $60M, the Ethereum community faced a choice: accept the loss or hard fork to reverse the transactions. The fork that returned funds became 'Ethereum' (ETH); those who refused became 'Ethereum Classic' (ETC). The controversy around the fork remains philosophically significant — it tested the principle of code-is-law versus social consensus to protect victims.
How can I check if a contract is vulnerable to reentrancy?
Manual review: look for external calls (ETH transfers, token transfers, arbitrary calls) that occur BEFORE state updates in the same function. Automated tools: Slither (static analysis), Echidna (fuzzing), MythX, and Certora Prover can detect reentrancy patterns. The most dangerous pattern is ERC-777 token transfers or ETH sends to arbitrary addresses mid-function. Formal verification provides the strongest guarantees but is resource-intensive.
Related Terms
Smart Contract Risk
Smart contract risk is the danger that a bug, vulnerability, or unexpected logic in a protocol's code could lead to the loss or theft of user funds. It is the most common "non-market" risk in DeFi.
Flash Loans
Flash loans are uncollateralized DeFi loans that must be borrowed and repaid within a single blockchain transaction. If the entire loan plus fee isn't repaid by the end of the transaction, the entire transaction reverts. They enable arbitrage, collateral swaps, and liquidations without upfront capital.
Cross-Chain Bridge Risks
Cross-chain bridges have become the largest attack surface in DeFi, with over $2 billion stolen in bridge hacks through 2022–2024. Key risks include validator compromise, smart contract bugs, economic exploits, and centralization vulnerabilities that aren't present in native chain transactions.
EVM (Ethereum Virtual Machine)
The Ethereum Virtual Machine (EVM) is the sandboxed runtime environment that executes smart contract code on Ethereum and EVM-compatible blockchains. Every node runs an identical copy of the EVM, ensuring that the same smart contract executed with the same inputs always produces the same output.
Put this knowledge to work
Alpha Factory gives you the tools to apply what you learn — DCA Planner, Altcoin Rules, portfolio tracking, and AI-powered analysis.
Start Free Trial