A reentrancy attack is a software flaw where a call into a contract or function can be re-entered before the first call finishes, letting an attacker repeat actions in an unsafe order. In smart contracts, this can drain funds or corrupt state if balances are updated after external calls.
How Reentrancy Attacks Work
Reentrancy happens when a contract makes an external call before it has finished updating its own state, and the callee re-enters the original function while the first execution is still in progress. The problem is not the call itself, but the unsafe ordering that lets one logical action be executed more than once.
In practice, this means the contract can briefly expose a stale balance, stale allowance, or other not-yet-updated state. If the re-entering path can trigger the same value transfer or state change again, the attacker may amplify a single interaction into repeated withdrawals or inconsistent bookkeeping.
Why Reentrancy Becomes Dangerous
Reentrancy is dangerous because it breaks the assumption that each function call is atomic from the contract’s point of view. Smart contracts often rely on execution order to protect assets and invariants, so a callback that runs before final state updates can undermine the very checks the code was meant to enforce.
The issue is especially serious in contracts that send value, call untrusted external code, or depend on balances and counters remaining synchronized. Smart Contract Security Guide covers this vulnerability class alongside the broader patterns that make smart contracts brittle under unexpected control flow.
Common Failure Patterns and Exposure Checks
The classic failure pattern is “effects after interactions”, where the contract transfers control outward before recording that funds were spent or state changed. Similar exposure appears when the contract relies on shared mutable state, nested callbacks, or token and vault logic that assumes no second entry can happen mid-execution.
To check exposure, reviewers look for any external call made before critical state mutation, especially in withdrawal, claim, mint, redeem, or accounting functions. They also verify whether the contract’s invariants still hold if the same entry point is called again before the first invocation completes.
Secure Design and Defensive Patterns
The safest designs reduce the chance that untrusted external code can observe or influence intermediate state. Developers typically write contracts so that state is updated before any external interaction, and so that repeated entry cannot replay the same privileged action or value transfer.
Defense in depth also includes minimizing external calls inside sensitive functions, isolating risky integrations, and testing reentry paths during review and fuzzing. For broader smart contract hardening guidance, the smart contract security guide is the most direct internal reference, while OWASP API Security Top 10 is useful for thinking about broken authorization and unsafe service interaction patterns that often coexist with poor control flow discipline.
Risk and Threat Considerations
Reentrancy is a direct asset-loss and state-integrity risk because an attacker can repeatedly trigger the same sensitive logic before the contract records that the first action already happened. In funds-handling contracts, that can turn a single legitimate call into multiple withdrawals or corrupted accounting.
Failure mechanism: The contract performs an external call before finalising its own state, and the callee re-enters the vulnerable function while the original execution still reflects stale balances or flags.
Impact: The attacker may drain value, bypass intended one-time limits, or leave the contract in an inconsistent state that breaks later operations and recovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, OWASP SAMM, 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 | V15 — Secure Coding and Architecture | Reentrancy is a secure-coding and architecture flaw in execution order. |
| Recommendation — Design state changes to complete before external calls and review control flow for reentry paths. | ||
| OWASP SAMM | DS — Design Security | Reentrancy belongs to design-time security analysis and threat-aware architecture review. |
| Recommendation — Assess sensitive workflows for unsafe callback ordering during design and threat modeling. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Reentrancy is often prevented by constraining unsafe external interaction paths and validating flow assumptions. |
| Recommendation — Constrain external interactions in sensitive functions and verify assumptions before accepting execution state. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Reentrancy is a secure application development weakness addressed by application security practices. |
| Recommendation — Embed secure coding review and testing to catch reentrancy-prone logic before release. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | A reentrancy attack is an application exploit path against exposed contract logic. |
| Recommendation — Map exploited contract entry points to public-facing application abuse and monitor for repeated call patterns. | ||
Practitioner Guidance
Why practitioners should care: Reentrancy is not just a code-style issue, it is a direct control-flow trust problem. Teams should treat any external call inside a value-moving or state-critical path as a review hotspot, because the exploit condition is often created by ordinary-looking business logic.
Common misunderstanding: Developers sometimes assume that checking a balance or permission once at the start of a function is enough. For reentrancy-sensitive code, that assumption fails if the function can be re-entered before the state change is committed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org