Reentrancy Attacks: The Exploit That Keeps Coming Back

The OWASP Smart Contract Top 10 for 2026, published this month, cataloged 122 distinct smart contract incidents from 2025 totaling 905.4 million dollars in losses. Reentrancy remains a top-five vulnerability category. The latest high-profile case: Solv Protocol lost 2.7 million dollars when an attacker exploited a callback mechanism in the ERC-3525 semi-fungible token standard to re-enter the minting function before the transfer state was finalized, creating duplicate token positions. For a compliance officer or software architect evaluating DeFi exposure, the persistence of this vulnerability class across nearly a decade of smart contract development is the signal that matters more than any individual exploit.

How the Attack Works

A reentrancy attack exploits a specific ordering problem. When a contract sends funds to an external address, the receiving contract can execute arbitrary code before the sender finishes updating its internal state. If the contract checks a balance, sends funds, and then updates the balance, the receiver can call back into the withdrawal function during the transfer, before the balance is decremented. The result is a recursive drain loop that continues until the contract is empty or gas runs out. In architecture terms, this is a violation of atomicity: state read and state write are separated by an external call transferring execution control to untrusted code.

The DAO hack of 2016 drained approximately 60 million dollars in ETH using exactly this pattern, an event severe enough to cause Ethereum's hard fork.

Why It Persists

Three factors explain why reentrancy continues to cause losses nearly a decade after the DAO hack. First, new token standards introduce new callback surfaces. ERC-721 tokens trigger callbacks on transfer. ERC-1155 tokens have batch transfer hooks. ERC-3525 semi-fungible tokens, the standard Solv Protocol used, include transfer callbacks that execute recipient code mid-transaction. Each new standard creates a new attack surface that developers may not recognize as reentrancy-vulnerable because it does not look like the classic ETH withdrawal pattern.

Second, cross-function and cross-contract reentrancy are harder to detect than single-function reentrancy. An attacker does not need to re-enter the same function. They can re-enter a different function in the same contract, or a function in a different contract that shares state. The Curve Finance pool exploit of July 2023, which caused approximately 70 million dollars in losses, exploited a cross-function reentrancy vulnerability in Vyper, a language that was assumed to be immune because of its compiler design.

Third, audit coverage is incomplete. The OWASP report notes that existing detection tools identified only 11.3 percent of exploitable victim contracts in a study of 159 known vulnerable contracts. The gap between what automated tools can detect and what attackers can find remains wide.

Real Defenses vs Fake Defenses

The real defenses are well-established. The Checks-Effects-Interactions pattern requires that a function verify conditions, update state, and only then make external calls. OpenZeppelin's ReentrancyGuard modifier implements a mutex lock that prevents any function marked nonReentrant from being called while another nonReentrant function is executing. The gas cost of this protection is 2,500 to 5,000 per guarded function call, a negligible expense relative to the assets at risk.

Fake defenses include relying on gas limits to prevent reentrancy, which is unreliable because gas costs change with network upgrades, and assuming that a contract is safe because it does not handle ETH directly. Any token standard with transfer callbacks creates reentrancy risk regardless of whether native ETH is involved.

Read-only reentrancy is an emerging variant that exploits view functions. An attacker re-enters a view function that reads stale state during an incomplete transaction, causing other protocols that rely on that state to make decisions based on incorrect data. This does not drain the vulnerable contract directly but can be used to manipulate oracle prices or lending protocol valuations.

Early Warning Indicators

A software architect monitoring for reentrancy risk would check three things before deployment: whether all state-changing functions follow Checks-Effects-Interactions or use reentrancy guards, whether the contract interacts with any token standard that includes transfer callbacks, and whether cross-function reentrancy scenarios have been tested. Post-deployment, tools like Forta Network and OpenZeppelin Defender can detect anomalous recursive call patterns in real time.

Residual Risk

The residual risk statement for reentrancy is direct: any smart contract that makes external calls to untrusted code before completing all state updates is vulnerable. The defenses are mature and well-documented. The reason losses continue is not that defenses are unavailable but that developers either do not apply them consistently or do not recognize new callback surfaces as reentrancy vectors. For an allocator evaluating DeFi protocol risk, the question to ask is not whether a protocol has been audited but whether the audit specifically tested for cross-function and cross-contract reentrancy across every token standard the protocol interacts with.

For informational purposes only. Not an offer to buy or sell any security. Available only to accredited investors who meet regulatory requirements.

‍