hunting-smart-contract-reentrancy

Hunting smart-contract reentrancy: acting on state that has not been updated yet

Reentrancy is a control-flow bug: a contract makes an external call before it finishes updating its own state, and the callee, which the attacker controls, calls back in and finds the old state still in place. The classic shape is sending value before zeroing a balance, but it generalizes to any effect that lands after an interaction, across functions that share state and through callback hooks that hand the attacker control mid-update. This is a crowded topic, so the value is not naming the pattern but killing the lead that a guard or an already-updated state defeats. The dividing line from access control: if the fix is to reorder effects before interactions or add a mutex, it is reentrancy and belongs here; if the fix is to add or repair an authorization check, it belongs in the access-control skill.

When to use

• A function makes an external call (sends value, calls a token, invokes an attacker-supplyable address).
• State that the function or a sibling depends on is updated after that external call.
• You want to know whether an attacker can re-enter and act on state that has not been updated yet.

Scope check

Analyze only contracts you own or are authorized to assess, and exercise a reentrancy path only on a test network or a local fork, never against live value, an exploit here moves real funds irreversibly. Prove it against a fork. If you can't name the authorization, stop.

The loop

1. Map external calls against state updates first. For each function, find every external call (a value transfer, a token call, a call to a supplied address) and every state update the function and its siblings depend on, and record which comes first. Reentrancy exists only where an effect lands after an interaction; establish that ordering before anything else.

2. Check single-function reentrancy. Look for a function that performs an external call before updating the state that call's safety depends on, the withdraw-before-zeroing shape, so a re-entrant call sees the pre-update balance and repeats the withdrawal.