What Is a Reentrancy Attack? The DAO Hack Explained

A reentrancy attack is a smart contract exploit in which a malicious contract repeatedly calls back into a vulnerable function before that function has finished updating its own internal records, allowing the attacker to repeat an action — most commonly a withdrawal — multiple times before the contract realizes it should have stopped. The most famous historical example is the 2016 attack on The DAO, which drained a large portion of its held ETH and led to a contentious hard fork of Ethereum.

The vulnerable pattern

The root cause of reentrancy is ordering: a function that sends ETH or tokens out to an external address before updating its own internal accounting of what that address is owed. Consider a simplified withdrawal function that (1) checks the caller's balance, (2) sends them that balance in ETH, and then (3) sets their recorded balance to zero. If step 2 involves calling an external address, and that address is itself a contract, the receiving contract's code executes as part of that transfer — and if its code immediately calls back into the same withdrawal function before step 3 has run, the balance still shows the original amount, and the transfer happens again. This can repeat many times within the same outer transaction, since step 3 never got a chance to run.

Why this exploits how external calls work

In Solidity (see /blog/what-is-solidity-programming-language), sending ETH to an address can trigger that address's own code to run automatically if the address is a contract. This handoff of execution control is normal and necessary for much of what smart contracts do, but it means a contract calling an untrusted external address is momentarily handing over control of its own execution flow — and if internal bookkeeping hasn't been finalized yet, that handoff can be abused.

What happened in The DAO hack

The DAO was an early, high-profile decentralized investment fund built on Ethereum, governed by token holders through smart contract logic — a very early example of the structures now covered in /blog/what-is-a-dao-ethereum. Its withdrawal function contained exactly this vulnerable ordering. An attacker exploited it with a malicious contract that recursively called back into the withdrawal function before the balance update executed, repeatedly draining ETH in a way the contract's designers had not anticipated. Roughly a third of the funds held by The DAO at the time were drained before the attack was halted.

The aftermath and the hard fork

The scale of the loss led the Ethereum community into an unusually public and contentious debate: should the chain's history be altered to reverse the theft, or should the principle that "code is law" — that blockchain outcomes, once executed, are final regardless of intent — be upheld even in this case? Ethereum's core developers and a majority of the community ultimately implemented a hard fork (the mechanics of which are described generally in /blog/how-ethereum-hard-forks-work) that effectively reversed the attack's effects, returning the drained funds to a recovery contract. A minority of the community rejected this intervention on principle and continued running the original, unaltered chain — which persists today as a separate network.

How reentrancy is defended against today

Defense	How it works
Checks-effects-interactions pattern	Update internal state before making any external call
Reentrancy guards	A modifier that blocks a function from being re-entered while it's already executing
Pull-over-push payments	Let recipients withdraw funds themselves rather than the contract pushing funds out
Gas-limited external calls	Restricting how much computation an external call can perform, limiting what malicious code can do

These defenses are now considered standard practice, part of the baseline knowledge covered in /blog/common-smart-contract-vulnerabilities, and a routine check in any serious /blog/how-to-audit-a-smart-contract process.

Cross-function and cross-contract reentrancy

The classic reentrancy example involves a single function calling back into itself, but more subtle variations exist. Cross-function reentrancy occurs when a malicious call re-enters a different function in the same contract that shares vulnerable state with the one initially called, exploiting the same underlying ordering flaw through a less obvious path. Cross-contract reentrancy extends this further, where the re-entrant call targets a completely separate contract that happens to share state or depend on the same external system, making the vulnerability harder to spot by looking at any single function in isolation. These variations are part of why thorough security reviews, as described in /blog/how-to-audit-a-smart-contract, examine a contract's full set of interactions rather than checking each function purely on its own.

Why this history still matters

Reentrancy attacks, in various forms, have continued to occur in newer protocols over the years since The DAO — the specific vulnerability is well understood, but variations on it still slip through when developers deviate from the standard defensive patterns. The DAO hack remains the reference case not because it was the only one, but because of its scale and its lasting effect on Ethereum's history and philosophy around immutability.

Bottom line

A reentrancy attack exploits a contract that makes an external call before finishing its own internal bookkeeping, letting an attacker repeat an action multiple times within a single transaction. The DAO hack is the defining historical example, both for the exploit itself and for the hard fork it triggered — a decision that continues to shape debates about immutability in Ethereum today.