Call Stack Reentrancy

Unlike classical reentrancy, this attack occurs within a single transaction and function execution. The attacker does not re-enter the same function via a callback. Instead, they manipulate the order of operations and state changes between multiple external calls made by the vulnerable function.

• The vulnerable function makes several external calls.
• The attacker's contract intercepts one call, executes custom logic, and then calls back into the original contract before the vulnerable function's final state update.

The core vulnerability is a temporary state inconsistency between internal accounting and external asset transfers. The contract updates its internal balance after making external calls, creating a window where the recorded state does not reflect reality.

For example, a contract might:

1. Transfer tokens to a user.
2. Then decrement its internal balance ledger.

An attacker can exploit the gap between step 1 and step 2.

The attack is typically enabled by the use of low-level call operations (e.g., addr.call{value: x}("")) instead of higher-level transfer methods. call forwards all remaining gas by default and does not throw an exception on failure unless explicitly checked, allowing the recipient's fallback function to execute complex logic and make further calls back to the sender.

This is a direct violation of the Checks-Effects-Interactions pattern, the primary defense against reentrancy. The secure pattern mandates:

1. Checks: Validate all conditions (e.g., balances, permissions).
2. Effects: Update all internal state variables.
3. Interactions: Perform external calls last.

Call stack reentrancy exploits contracts that perform Interactions before completing all Effects.

The attacker's callback often targets a different function in the same vulnerable contract, one that relies on the inconsistent state. For instance, after receiving funds in step 1, the callback might invoke a withdraw() function that checks the same, not-yet-updated balance ledger, allowing a double spend.

This makes the attack more subtle than direct reentrancy, as the malicious code path differs from the initially called function.

The standard mitigation is a reentrancy guard modifier, such as OpenZeppelin's ReentrancyGuard. It uses a boolean lock (nonReentrant) that is set on entry and cleared on exit of a function, preventing any function with the modifier from being called recursively within the same transaction.

• Best Practice: Apply nonReentrant to any function that makes external calls.
• Fundamental Fix: Strictly adhere to the Checks-Effects-Interactions pattern.

The exploit occurs when a contract makes an external call to an untrusted contract before updating its own internal state. The malicious contract's fallback or receive function reenters the calling function, which sees outdated state variables. This allows repeated withdrawals or unauthorized actions, as seen in the infamous DAO hack of 2016.

The primary defense is to strictly follow the Checks-Effects-Interactions (CEI) pattern:

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

A common technical mitigation is a reentrancy guard, a boolean lock that prevents a function from being called recursively. OpenZeppelin's ReentrancyGuard contract provides a nonReentrant modifier. When applied to a function, it sets a lock for the duration of execution, causing any reentrant call to revert. This is a robust solution but adds gas overhead and should not replace proper state management via CEI.

Reentrancy attacks manifest in two primary forms:

• Single-Function Reentrancy: The attacker reenters the same function they initially called (e.g., a withdraw function). This is the classic pattern.
• Cross-Function Reentrancy: The attacker uses an external call to reenter a different function in the same contract that shares state with the vulnerable function. This can be more subtle and harder to guard against, as it bypasses single-function locks.

Beyond direct fund theft, reentrancy can cause state corruption and business logic failures. An attacker might not drain ETH but could manipulate voting weights, mint unlimited tokens, or bypass access controls by exploiting intermediate state. For example, a function that calculates rewards based on a user's balance before updating it could be tricked into paying out inflated amounts repeatedly.

The 2016 DAO attack, which exploited a reentrancy bug to drain 3.6 million ETH (worth ~$50M at the time), remains the most famous example and led to the Ethereum hard fork. While awareness and tools like CEI and guards have reduced simple attacks, reentrancy remains a top vulnerability in smart contract audits. Complex DeFi protocols with intricate callback mechanisms require diligent review to prevent novel reentrancy vectors.

The fundamental design pattern for preventing reentrancy. It mandates a strict execution order:

• Checks: Validate all conditions and inputs (e.g., balances, permissions).
• Effects: Perform all state updates (e.g., deducting balances, updating counters).
• Interactions: Make external calls to other contracts or addresses only after all state is finalized. This ensures the contract is in a consistent state before any external interaction that could trigger a reentrant call.

A mutex (mutual exclusion) mechanism that locks a function during execution. A boolean state variable (e.g., locked) is set to true at the start of the function and false at the end. Any reentrant call will fail the initial check, preventing recursive execution. This is a robust, generalized solution, famously implemented in OpenZeppelin's ReentrancyGuard contract.

Instead of a contract pushing funds to users (an external call that can be hijacked), users pull funds themselves. The contract updates an internal accounting balance (an effect) and provides a separate withdraw function. This separates the state-changing logic from the fund transfer, eliminating the reentrancy vector in the core logic. This pattern is also more gas-efficient for batch operations.

Call stack depth limits and gas stipends for legacy send/transfer were historical mitigations. However, with the 63/64 rule for call depth and EIP-1884 increasing opcode costs, these are no longer reliable primary defenses. Relying on transfer() or send() (which forward a 2300 gas stipend) can lead to failures with gas-costly fallback functions. Use the CEI pattern or guards instead.

A specific failure mode occurs when state variables are updated in the wrong order. For example, updating a user's balance after making an external call creates a window for reentrancy. The attacker's fallback function can call back into the contract, and because their balance hasn't been deducted yet, they can drain funds. Always update critical state before any external call.

Proactive tools to detect potential vulnerabilities:

• Static Analysis: Tools like Slither or MythX can automatically flag functions that make external calls after state changes or lack reentrancy guards.
• Formal Verification: Using tools like Certora or modeling in TLA+ to mathematically prove that a contract's state machine cannot enter an invalid state, regardless of call order. These are essential for high-value protocols.

A more subtle variant where an attacker reenters a different function in the same contract that shares state. This bypasses simple single-function guards. Example: An attacker calls Function A, which makes an external call. The malicious contract's fallback then calls Function B, which relies on state that Function A hasn't finished updating. Defenses require careful application of the Checks-Effects-Interactions pattern across the entire contract's state model.

Demonstrates how token standards can introduce new reentrancy vectors. ERC-777 tokens have tokensToSend and tokensReceived hooks that are called during transfers. Attack Vector: A contract receiving tokens could reenter the sender's contract via the hook before the sender's balance is updated. This led to incidents like the Uniswap/Lendf.Me hack in 2020, where an attacker used an ERC-777 token's hook to manipulate a lending market's internal accounting.

The foundational coding pattern to prevent reentrancy, mandated as a best practice post-DAO.

1. Checks: Validate all conditions and inputs (e.g., require(balance[msg.sender] >= amount)).
2. Effects: Update all internal state variables (e.g., balance[msg.sender] -= amount).
3. Interactions: Perform external calls last (e.g., msg.sender.call{value: amount}("")). By performing interactions last, the contract's state is already in a consistent state, eliminating the reentrancy vulnerability.

Today, reentrancy is a primary target for automated security tools.

• Static Analysis: Slither and MythX can detect common reentrancy patterns by analyzing control flow graphs.
• Formal Verification: Tools like Certora and SMTChecker can mathematically prove the absence of reentrancy under specified conditions.
• Fuzzing & Invariant Testing: Foundry and Echidna can simulate complex transaction sequences to uncover cross-function and cross-contract reentrancy paths that static analysis might miss.