A Reentrancy Attack is a vulnerability where external calls allow malicious contracts to recursively call back before state updates complete.

Attack Mechanism Explained

Reentrancy exploits occur through a specific sequence of contract interactions. Contract A initiates an external call to Contract B, transferring control flow to the external contract. Before Contract A completes its state updates, Contract B recursively calls back into Contract A, re-entering the original contract while it remains in an inconsistent state. This allows Contract B to exploit invariants that Contract A assumes are maintained but have not yet been enforced through state updates. The vulnerability arises from the fundamental property that external calls transfer execution control before the calling contract finalizes its state changes.

The DAO Hack: Historical Context

The most notorious reentrancy attack targeted The DAO in 2016, resulting in theft of over $60 million in ETH. The severity and systemic implications of this exploit led to the controversial Ethereum hard fork that created the ETH/ETC split, fundamentally shaping blockchain governance debates. The attacker exploited a withdrawal function that updated user balances only after transferring funds, enabling recursive withdrawal calls that drained the contract. Each reentrant call executed before balance updates, allowing the attacker to withdraw the same funds repeatedly until the contract was depleted.

Vulnerable Pattern

1function withdraw() external {
2    uint256 amount = balances[msg.sender];
3    // External call BEFORE state update
4    (bool success, ) = msg.sender.call{value: amount}("");
5    require(success);
6    balances[msg.sender] = 0; // TOO LATE!
7}

Protection Mechanisms

1. Checks-Effects-Interactions Pattern

1function withdraw() external {
2    uint256 amount = balances[msg.sender];
3    balances[msg.sender] = 0; // Update state FIRST
4    (bool success, ) = msg.sender.call{value: amount}("");
5    require(success);
6}

2. Reentrancy Guards

1modifier nonReentrant() {
2    require(!locked);
3    locked = true;
4    _;
5    locked = false;
6}

Comprehensive Protection Strategies

Defending against reentrancy requires multiple layers of security practices. Always update state before external calls following the Checks-Effects-Interactions pattern, ensuring contract invariants are established before transferring control. Utilize battle-tested libraries like OpenZeppelin's ReentrancyGuard, which provides standardized mutex implementations that prevent recursive calls.

Limit external calls to trusted contracts when possible, though recognize that trust assumptions can be violated through proxy patterns or compromised implementations. Comprehensive testing with malicious contracts should simulate reentrant attack scenarios, verifying that protection mechanisms function correctly. Thorough auditing of all external call patterns must identify every location where control transfers to untrusted code, ensuring appropriate safeguards exist at each interaction point.