Reentrancy Attack Explained with Real Examples

Reentrancy Attack Explained with Real Examples

Reentrancy is one of the oldest and still most dangerous vulnerabilities in smart contracts.
It looks simple on paper, yet it has drained hundreds of millions of dollars over the years.

In short, a reentrancy attack happens when a contract calls an external address before it finishes updating its own state. The external contract can then call back into the original function and repeat the action while the state is still outdated.

How a Classic Reentrancy Attack Works

The classic pattern looks like this:

1. The contract checks the user’s balance
2. It sends the ETH (or tokens)
3. Only after the transfer does it update the balance to zero

If the recipient is a malicious contract, receiving the ETH triggers its fallback or receive function. That function immediately calls the withdraw function again. Because the balance hasn’t been reduced yet, the contract happily sends the money once more. This repeats until the contract is drained or the transaction runs out of gas.

This is exactly what happens when developers break the Checks-Effects-Interactions pattern.

Real-World Examples

The DAO Hack (2016)

The most famous case.
The DAO had raised roughly $150 million worth of ETH. An attacker exploited the splitDAO function, which sent ETH before updating the internal balance. Through recursive calls, the attacker drained about 3.6 million ETH (around $60 million at the time).

The incident was so severe that it forced the Ethereum community to hard-fork, creating Ethereum Classic in the process.

Cream Finance (2021)

Attackers used an ERC-777 token’s callback mechanism to achieve cross-function reentrancy. The protocol lost more than $29 million.
This showed that even after years of awareness, new token standards can reopen the same class of vulnerability.

More Recent Variants

Between 2023 and 2025 we saw several “read-only reentrancy” attacks (notably affecting Curve pools and protocols that relied on them). In these cases the attacker doesn’t steal funds directly. Instead they manipulate price oracles during the callback window, allowing other protocols to issue under-collateralized loans.

At Panda Security we still regularly find reentrancy issues during audits — not always the classic single-function version, but more subtle cross-function or cross-contract variants that developers thought they had already protected against.

Our Take at Panda Security

After reviewing hundreds of contracts, we’ve noticed a common pattern: teams treat ReentrancyGuard as a silver bullet.

It’s useful, but it only stops direct reentrancy into the same function. It does not automatically protect against:

• Cross-function reentrancy
• Cross-contract reentrancy
• Read-only reentrancy

The most reliable defense is still discipline: update all relevant state before any external call, then add a reentrancy lock as a second layer.

Practical Prevention Tips

1. Follow Checks-Effects-Interactions strictly
   Check conditions → update state → only then make external calls.

2. Use OpenZeppelin’s ReentrancyGuard
   Apply the nonReentrant modifier to every function that changes balances or makes external calls.

3. Be extra careful with callbacks
   ERC-777, ERC-721, ERC-1155, and custom hooks are frequent attack vectors.

4. Test the reentrancy paths
   Write explicit tests that try to re-enter your functions. Fuzzing helps a lot here.

Reentrancy has been around for a decade, yet it keeps appearing in new forms. Understanding the root cause — and respecting the order of operations — is still the best protection.

If you’re preparing a protocol for mainnet and want a second pair of eyes on reentrancy and related issues, the Panda Security team is happy to help.