A Reentrancy Attack is used against smart contracts that call external code before updating their own state, allowing an attacker to re-enter the function and repeat the withdrawal or action. Defenders should follow checks-effects-interactions, use reentrancy guards, and review any contract that sends funds or makes external calls.
How attackers exploit reentrancy in smart contracts
Reentrancy works when a contract makes an external call before it has finished updating its own state. That creates a window where the attacker’s callback can invoke the same function again and see stale balances, stale allowances, or other unchanged state. The attacker is not breaking cryptography, they are exploiting execution order.
The practical pattern is simple: trigger a function that sends value or calls into another contract, then use the receiving contract to re-enter before the first execution completes. If the contract assumes the first call has already “finished” its accounting, repeated withdrawals or duplicated actions become possible.
In many cases the attacker’s advantage comes from relying on a state mismatch, not from unusual access. Any function that transfers funds, changes ownership, updates quotas, or performs external callbacks can become a target if the contract treats the external call as safe before the internal state is committed.
Why checks-effects-interactions is the core defensive pattern
Reentrancy is fundamentally a sequencing problem. The safe pattern is to validate inputs first, update internal state second, and only then interact with external contracts or accounts. That order reduces the chance that a callback can observe a still-open transaction path and repeat the same action.
Reentrancy guards add another layer by blocking nested entry into the same function while it is executing. They are useful, but they are not a substitute for correct ordering, because the safest design is still to minimise the attack surface by avoiding unnecessary external calls during sensitive state transitions.
Any code path that sends funds, mints tokens, updates claimable balances, or triggers hooks deserves extra scrutiny. The more valuable the action being performed, the more damaging a successful re-entry becomes.
Where reentrancy remains risky in real contracts
Risk rises when a contract mixes value transfer with business logic and assumes that external calls will behave benignly. A single overlooked callback can let an attacker chain the same function multiple times before the contract records the first change.
This is especially dangerous in systems with shared pools, vaults, escrow logic, reward claims, or upgradeable contracts where one unsafe function can expose a larger balance or state machine. A small sequencing flaw can become a systemic loss event.
For deeper patterns in contract design, audits, and exploit classes, see the Smart Contract Security Guide. Attackers look for any path where external execution happens before the contract has fully closed the loop on its own accounting.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Reentrant callbacks can bypass intended action limits and authorisation checks. |
| V15 — Secure Coding and Architecture | Reentrancy is a code-structure flaw caused by unsafe interaction ordering. | |
| Recommendation — Recheck authorisation after state changes and before any sensitive external interaction. Design sensitive functions to update state before external calls and minimise callback exposure. | ||
| NIST SP 800-53 Rev 5 | SC-3 — Security Function Isolation | Reentrancy exploits weak isolation between internal state changes and external execution. |
| SI-10 — Information Input Validation | Unchecked interaction flow and assumptions about caller behaviour enable repeated exploitation. | |
| Recommendation — Isolate sensitive execution paths so external code cannot re-enter unfinished logic. Validate inputs and execution paths before permitting state-changing operations. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Smart contract reentrancy is an application logic flaw needing secure design and review. |
| Recommendation — Test application logic for callback-driven abuse and fix unsafe call ordering. | ||
Practitioner Guidance
What to verify: Review every external call in the contract and confirm whether state is fully updated before control can leave the function. Pay special attention to withdrawals, reward claims, token transfers, upgrade hooks, and any function that invokes another contract.
Decision rule: If a function can move value or change critical state, treat any external call inside that function as a reentrancy candidate until proven otherwise. If the contract must call out, make the internal state change first and keep the callable surface as small as possible.
Common mistake: Developers often assume a reentrancy guard alone solves the problem. In practice, the better question is whether the design still permits unsafe re-entry at all, because defence-in-depth is strongest when ordering, guards, and code review all agree.
Practitioner takeaway: Reentrancy is usually an execution-order failure, so the right mindset is to assume any external call can come back immediately and test whether the contract is still safe at that point.