Reentrant Call

A reentrant call exploits the sequential nature of state updates in smart contracts. The vulnerability occurs when a contract:

• Sends funds (e.g., via call.value()) to an untrusted address.
• Updates its internal state (e.g., reducing the user's balance) after the external call. An attacker's contract can execute a fallback or receive function that calls back into the vulnerable function before the balance is deducted, allowing repeated withdrawals from the same initial balance.

The primary defense against reentrancy is the Checks-Effects-Interactions (CEI) pattern. This coding standard mandates a strict order of operations:

1. Checks: Validate all conditions and inputs (e.g., require(balance >= amount)).
2. Effects: Update all internal state variables before any external calls (e.g., balances[msg.sender] -= amount).
3. Interactions: Perform external calls to other contracts or addresses last. By updating state first, any reentrant call will see the already-modified balance, preventing double-spending.

A reentrancy guard is a code-level lock that prevents a function from being called recursively. It uses a boolean state variable (e.g., locked) that is set to true on entry and false on exit. The OpenZeppelin ReentrancyGuard contract provides a standard nonReentrant modifier. When applied to a function, any reentrant call will fail the require(!locked) check, providing a robust, single-line defense. This is considered a best practice for any function performing external calls.

The most famous reentrancy attack was the 2016 DAO hack, which resulted in the theft of 3.6 million ETH (worth ~$50M at the time). The vulnerable splitDAO function in The DAO's contract sent ETH to an attacker before updating the attacker's internal token balance. The attacker's fallback function repeatedly re-entered splitDAO, draining funds in a loop. This event directly led to the Ethereum hard fork that created Ethereum (ETH) and Ethereum Classic (ETC).

Reentrancy is not limited to a single function. Cross-function reentrancy occurs when an attacker's callback re-enters a different function in the same contract that shares state. Cross-contract reentrancy involves re-entering a separate contract that shares a common state variable (e.g., a pair of pools using the same token contract). These are subtler and harder to detect than single-function reentrancy, as the malicious path doesn't directly loop within one function.

Modern token standards like ERC-777 and ERC-1155 introduce built-in hooks (tokensToSend, tokensReceived, onERC1155Received). These are callback functions that execute during a token transfer. If a contract's logic is sensitive to token balances and performs actions after a transfer, these hooks can be used to launch a reentrant attack before the contract's state is finalized. Developers must apply the CEI pattern and reentrancy guards even when using these standards.

The attack exploits the order of operations in a function. A typical pattern is:

• 1. Contract A sends funds to Contract B.
• 2. Contract B's fallback/receive function is triggered.
• 3. Before Contract A's state (like balance) is updated, Contract B calls back into Contract A's original function.
• 4. Contract A sees its old, unchanged balance, allowing the same withdrawal to repeat. This creates a recursive loop that drains assets.

The most famous reentrancy attack resulted in the theft of 3.6 million ETH (worth ~$50M at the time) from The DAO, leading to the Ethereum hard fork. The vulnerable splitDAO function sent ETH before updating the user's internal token balance. The attacker's contract recursively called splitDAO, draining funds in a loop before the balance was set to zero.

The primary defense is a strict coding pattern:

1. Checks: Validate all conditions and inputs (e.g., require(balance > 0)).
2. Effects: Update all internal state variables (e.g., balances[msg.sender] = 0).
3. Interactions: Perform external calls to other contracts or addresses last (e.g., msg.sender.call{value: amount}("")). By updating state before interacting externally, you eliminate the reentrancy condition.

A common implementation uses a mutex lock. The nonReentrant modifier sets a boolean flag (_locked) when a function executes and reverts if re-entry is attempted.

solidityCopy
modifier nonReentrant() {
    require(!_locked, "Reentrant call");
    _locked = true;
    _;
    _locked = false;
}

Libraries like OpenZeppelin's ReentrancyGuard provide a standardized, audited version of this protection.

Reentrancy isn't limited to a single function.

• Cross-Function: An attacker re-enters a different function in the same contract that shares state (e.g., a withdraw function and a transfer function both use the same balance map).
• Cross-Contract: An attack involves multiple contracts that share state. Defending requires careful state isolation and applying the checks-effects-interactions pattern across the entire system.

Reentrancy often interacts with other flaws:

• Race Conditions: Similar to reentrancy, where outcome depends on sequence of events.
• Unchecked Call Return Values: Using low-level call without handling failure can compound reentrancy damage.
• ERC-777 Hooks: The tokensToSend/tokensReceived hooks can be used for reentrancy if state isn't secured. Audits must consider these composite risks.

The primary defensive programming pattern developed in direct response to reentrancy attacks like The DAO. It mandates a strict function structure:

• Checks: Validate all conditions (e.g., balances, permissions).
• Effects: Update all internal state variables (e.g., deduct balance).
• Interactions: Perform external calls to other contracts or users. This pattern prevents state corruption by ensuring all state changes are finalized before any external interaction occurs.

A standard modifier-based lock (nonReentrant) that uses a boolean state variable to prevent recursive function entry. Widely adopted in libraries like OpenZeppelin Contracts. Modern Solidity compilers also emit warnings for patterns that pose reentrancy risks. This represents the evolution from ad-hoc fixes to standardized, audited security primitives in smart contract development.

Reentrancy attacks fundamentally changed the smart contract security landscape, making static analysis for reentrancy a cornerstone of security audits. Tools like Slither and MythX include dedicated detectors. The severity of historical losses also accelerated research into formal verification methods to mathematically prove the absence of such vulnerabilities in critical contract code.

The 2016 attack on The DAO was the most famous exploit of a reentrancy vulnerability, leading to the theft of 3.6 million ETH. The attacker's contract repeatedly called back into the vulnerable withdrawal function before its balance was updated, draining funds in a recursive loop. This event directly caused the Ethereum hard fork that created Ethereum (ETH) and Ethereum Classic (ETC).

The primary defensive coding pattern to prevent reentrancy. It mandates a strict order of operations within a function:

• Checks: Validate all conditions and inputs (e.g., require(balance > 0)).
• Effects: Update all internal state variables (e.g., balances[msg.sender] = 0).
• Interactions: Perform external calls to other contracts or addresses (e.g., msg.sender.call{value: amount}("")). This ensures state is finalized before any external interaction occurs.

A modifier or mutex lock that prevents a function from being called recursively. Commonly implemented using a boolean state variable (e.g., locked) that is set to true at the function's start and false at its end. The OpenZeppelin ReentrancyGuard contract provides a standardized, audited implementation. While effective, it is considered a secondary defense; the Checks-Effects-Interactions pattern is more fundamental.

A more subtle variant where an attacker re-enters a different function in the same contract, exploiting shared state. For example, Function A calls an untrusted contract, which calls back into Function B of the original contract. If both functions read/write the same state variable (like a user's balance), the second call can operate on outdated or inconsistent data. Defending requires careful state management across all functions.

A design philosophy critical for security. Push payments actively send funds via transfer, send, or call and are vulnerable to reentrancy if state isn't updated first. Pull payments allow users to withdraw funds themselves from a designated balance mapping. This shifts the transaction initiation to the user, eliminating the reentrancy risk from the contract's outgoing call. It is the recommended pattern for complex payment systems.

Reentrancy is possible due to the Ethereum Virtual Machine's (EVM) design. An external call instruction temporarily yields control to the called contract's code. This code executes within the same transaction and with the same call stack limits as the caller. The caller's state remains fully accessible and mutable until the call returns, creating the window for recursive re-entry. Understanding this context is key to grasping the vulnerability's root cause.