What is a reentrancy attack in a smart contract?

A reentrancy attack exploits recursive function calls in smart contracts to drain funds, as seen in the infamous DAO hack.

Jul 15, 2025 at 02:50 am

Understanding the Basics of Smart Contracts

A smart contract is a self-executing contract with the terms directly written into code. It runs on blockchain platforms like Ethereum and automatically enforces agreements between parties without intermediaries. These contracts are immutable once deployed, meaning any vulnerabilities present in the code cannot be altered post-deployment. This immutability makes it crucial to ensure that smart contracts are secure from all possible exploits before they go live.

One such exploit is the reentrancy attack, which has been responsible for significant losses in the cryptocurrency ecosystem. Understanding how this vulnerability works requires a grasp of how smart contracts interact with external accounts and other contracts through function calls.

What Is a Reentrancy Attack?

A reentrancy attack occurs when a malicious contract repeatedly calls a vulnerable function in another contract before the initial execution completes. This recursive behavior can drain funds or manipulate state variables in unintended ways.

The classic example involves a contract handling Ether transfers. If a function sends Ether to an external address before updating its internal balance, a malicious contract can reenter the function during the transfer and drain the contract’s funds repeatedly. The infamous DAO hack in 2016, which led to a $60 million Ether loss, was a result of a reentrancy vulnerability.

How Does a Reentrancy Attack Work in Practice?

To better understand the mechanics of a reentrancy attack, consider the following simplified scenario:

• A contract has a withdraw() function that allows users to withdraw their deposited Ether.
• The function first sends Ether to the user using call.value(), then updates the user's balance to zero.
• A malicious contract registers itself as a user and deposits Ether into the target contract.
• When it calls withdraw(), the target contract initiates the Ether transfer.
• During the transfer, the malicious contract’s fallback function (which gets triggered automatically) calls withdraw() again.
• Since the balance hasn’t been updated yet, the contract believes the user still has funds available and sends more Ether.
• This loop continues until the contract is drained or the gas runs out.

This process exploits the order of operations within the contract—specifically, sending Ether before updating the state.

Types of Reentrancy Vulnerabilities

Reentrancy attacks come in several forms, each exploiting different aspects of contract logic:

• Single-function reentrancy: This occurs when a single function contains both external calls and state changes. An attacker triggers reentry during the external call before the state is updated.
• Cross-function reentrancy: Here, multiple functions share state variables. An attacker can reenter a second function while the first is still executing, manipulating shared data inconsistently.
• Delegatecall reentrancy: This advanced variant uses the delegatecall mechanism to execute code from one contract in the context of another. If not handled carefully, this can lead to unexpected reentrancy scenarios.

Each type requires careful auditing and specific mitigation strategies to prevent exploitation.

How to Prevent Reentrancy Attacks

Preventing reentrancy attacks involves adopting best practices in contract design and leveraging security tools:

• Use checks-effects-interactions pattern: Always update the contract’s state before making any external calls. This ensures that no reentry can manipulate pre-existing balances or states.
• Implement reentrancy guards: Libraries like OpenZeppelin provide reentrancy guard modifiers that use a mutex variable to block reentrant calls.
• Avoid complex external calls: Minimize interactions with unknown or untrusted contracts. Where necessary, ensure callbacks are safe and do not trigger arbitrary code.
• Use pull over push payments: Instead of pushing funds to users, let them initiate withdrawals. This reduces the risk of recursive draining.
• Conduct thorough audits: Use automated tools and manual reviews to detect potential reentrancy vectors in your codebase.

By applying these strategies, developers can significantly reduce the likelihood of a successful reentrancy attack.

Real-World Examples of Reentrancy Exploits

Several high-profile incidents highlight the devastating impact of reentrancy attacks:

• The DAO Hack (2016): The most famous case involved a decentralized autonomous organization whose smart contract allowed recursive withdrawals. Attackers exploited this to drain millions worth of Ether.
• Fusion Network Attack (2021): Hackers exploited a cross-function reentrancy bug in the protocol, leading to a $14 million loss.
• Warp Finance Hack (2021): Multiple reentrancy points were exploited across different functions, allowing attackers to drain nearly $8 million in assets.

These examples underscore the importance of rigorous testing and adherence to secure coding practices.

---

Frequently Asked Questions

Q: Can reentrancy attacks occur in non-Ethereum blockchains?

Yes, reentrancy attacks can affect any blockchain platform that supports smart contracts with external calls and mutable state. While Ethereum has seen the most prominent cases, similar vulnerabilities exist on Binance Smart Chain, Solana, and others.

Q: Are all external calls dangerous?

No, but external calls should be treated with caution. The danger arises when they are made before updating critical state variables. Proper coding patterns and safeguards can mitigate this risk.

Q: How do I test my contract for reentrancy vulnerabilities?

You can use static analysis tools like Slither or Securify, perform manual code audits, and simulate attack scenarios using frameworks like Brownie or Hardhat. Using reentrancy guards and following secure development practices also helps.

Q: What is the difference between a flash loan attack and a reentrancy attack?

While both can exploit DeFi protocols, a flash loan attack relies on borrowing large amounts of capital without collateral and repaying it within the same transaction. A reentrancy attack focuses on recursively calling functions to manipulate contract state. However, some attacks combine both techniques for greater impact.