Reentrancy Attack

Overview

Reentrancy occurs when a contract or program transfers control to external code and that code calls back before the original operation finishes. The repeated entry may observe or modify an intermediate state that designers assumed was unavailable.

Attacks can affect one function, multiple functions, contracts, tokens, or callbacks, and do not always involve a simple withdrawal loop. Read-only reentrancy can also expose inconsistent values to dependent protocols without directly changing the vulnerable state.

Mitigations include checks-effects-interactions, reentrancy guards, pull-based transfers, minimal external calls, invariant testing, and careful callback design. Developers must analyze all reachable entry points and integrations because local protection on one function may be insufficient.

Reentrancy Attack is an attack or weakness pattern that exploits external calls that re-enter vulnerable code before its previous execution has safely completed state updates. Reentrancy exploits unsafe intermediate state across control transfers, so defenses must cover all callbacks, functions, contracts, and dependent reads.

Assessment of Reentrancy Attack should trace an attack or weakness pattern that exploits external calls that re-enter vulnerable code before its previous execution has safely completed state updates from prerequisite and entry point through observable impact on the affected service. A theoretical weakness or scanner result involving attack should not be reported as exploitation without corroborating logs, transactions, or configuration evidence. Prevention, detection, containment, and recovery for the Reentrancy attack path should be tested against the architecture associated with attack.

Retesting for Reentrancy Attack should reproduce the Reentrancy attack path involving attack, examine adjacent paths, and verify the conditions for safely returning the affected service to normal operation.