A reentrancy guard is a control that blocks a function from being entered again before the first execution finishes. In smart contracts, it prevents an external call from re-entering the same code path and repeating state changes, which helps stop certain double-spend or balance-draining attacks.
What the control does in smart contract execution
A reentrancy guard is a stateful control that prevents a function from being entered again before the first call completes. It is used when a contract makes an external call and needs to preserve a single, orderly execution path through balance updates, ownership changes, or other state transitions.
That matters because smart contract execution can hand control to another contract mid-transaction. If the original function can be called again before its state is finalized, the contract may repeat a withdrawal, double-count a balance change, or reuse assumptions that were only safe for the first invocation.
Why reentrancy is dangerous
Reentrancy is not just a coding mistake, it is a control-flow weakness. The danger comes from the gap between a contract starting a sensitive action and the point where its internal state is actually made safe. If an attacker can re-enter through an external call, they may exploit that gap to trigger the same logic multiple times under one transaction context.
In practice, this class of flaw is especially damaging in systems that move value, update ledgers, or depend on invariants such as "the balance was already reduced." A reentrancy guard reduces that exposure by making the first invocation exclusive until completion, which is why it is often paired with safer state-update patterns and careful external-call ordering.
Where it fits in smart contract design
Reentrancy guards are part of broader smart contract safety, but they address one specific failure mode: repeated entry into a live function. They do not replace access control, input validation, or correct accounting logic. They work best as a defensive layer around functions that both mutate state and interact with untrusted external contracts.
Teams usually treat the guard as one control in a larger review of external call surfaces, fallback paths, callback behavior, and value-transfer logic. Smart Contract Security Guide is a useful broader reference for the surrounding vulnerability classes, while the OWASP Smart Contract Top 10 Guide places reentrancy in the context of other high-impact contract weaknesses.
How practitioners evaluate whether they need one
The practical question is not whether a contract contains external calls in the abstract, but whether those calls can occur before the contract has finished protecting its own invariants. If a function can transfer value, invoke another contract, and then continue relying on pre-call state, a reentrancy guard or equivalent design constraint is often warranted.
Reviewers also look for the surrounding conditions that make the control meaningful: state changes that happen after an external call, reusable execution paths, and sensitive operations that can be repeated without a fresh authorization decision. Where those conditions exist, the guard is a small mechanism with outsized value because it narrows the attack window to a single, non-reentrant execution.
Risk and Threat Considerations
Reentrancy is dangerous because it turns a normal external interaction into an attacker-controlled callback path. When the contract exposes value-moving or state-changing logic before it has finished updating its own state, the same action can be repeated inside one transaction, creating direct loss or invariant corruption.
Failure mechanism: An external call re-enters the original function before the first execution has completed, letting the attacker exploit partially updated state or repeat the same effect.
Impact: Funds can be drained, balances can be manipulated, and downstream accounting or authorization assumptions can be invalidated even when the original code appears correct in isolation.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Reentrancy guard enforces a single permitted execution path for a sensitive function. |
| V15 — Secure Coding and Architecture | Reentrancy is a design-level execution-flow flaw in contract architecture. | |
| Recommendation — Review authorization-sensitive flows so external callbacks cannot repeat protected state changes. Design contract logic to finalize state before any untrusted external interaction. | ||
| MITRE ATT&CK | T1055 — Process Injection | Reentrancy is an adversarial control-flow abuse pattern, though in smart contracts rather than processes. |
| Recommendation — Map repeated-entry behavior to control-flow abuse patterns when hunting for exploit sequences. | ||
Practitioner Guidance
What to watch for: Treat any function that mutates state and then makes an external call as a candidate for reentrancy review. The critical judgement is whether the function can be safely entered only once per transaction flow, or whether a callback could observe and exploit unfinished state.
Practitioner takeaway: A reentrancy guard is most effective when it supports, rather than substitutes for, a design that updates critical state before handing control to untrusted code.
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 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org