Read-only reentrancy is a smart contract flaw where a view or other non-state-changing call can be reentered and observe inconsistent data. In practice, an attacker exploits external callbacks during reads to manipulate on-chain logic, misleading price checks, balance queries, or risk controls without directly altering storage.
What Read-Only Reentrancy Means in Smart Contracts
Read-only reentrancy is a contract design flaw in which a seemingly harmless read call can be reentered through an external callback and return inconsistent state. The danger is not storage corruption, but misleading reads that other logic may trust.
Why Read-Only Reentrancy Is Dangerous
This class of bug matters because many DeFi and on-chain control paths treat read results as authoritative for pricing, collateral checks, limit checks, and routing decisions. If an attacker can influence what a read observes mid-execution, they can distort those decisions without needing to write directly to storage.
The result is a trust failure in the contract’s internal view of the world. A pool, oracle adapter, vault, or risk module may base follow-on logic on a snapshot that never truly existed as a stable state.
How the Exploit Works
Read-only reentrancy usually appears when a read path calls out to an external contract, token hook, oracle, or callback-capable dependency before the read has finished. The external code then reenters another path, changes the effective execution context, and causes the original reader to observe stale or inconsistent values.
Because the flaw sits inside a read flow, it can be missed by teams that focus only on write-path reentrancy. That makes it especially dangerous in contracts that assume view functions are always side-effect free in practice, even when they indirectly depend on external code.
Detection, Testing, and Defensive Design
Teams should test for any read path that crosses a trust boundary, especially where pricing, balances, reserve ratios, or health checks are derived from external calls. The most useful reviews trace whether a read can invoke untrusted code, whether that code can recurse into the system, and whether the result is consumed immediately by critical logic.
For a broader smart contract security baseline, the Smart Contract Security Guide is the natural starting point for understanding reentrancy, oracle manipulation, audits, and invariant testing. External references such as the OWASP API Security Top 10 and CSA Mythos-ready CISO security programme guidance can also help teams think about broken trust boundaries and control assumptions in adjacent systems.
Defensively, the key idea is to make reads deterministic and minimize external interaction during value calculation. When that is not possible, design the surrounding logic so an inconsistent read cannot directly steer a privileged or irreversible action.
Risk and Threat Considerations
Read-only reentrancy is risky because it can undermine the integrity of on-chain decision making without an obvious state-write signal. That makes it attractive in protocols where attackers want to bend pricing, liquidity, or risk logic while leaving storage unchanged.
Failure mechanism: An attacker induces an external callback during a read, then reenters a dependent path so the contract observes a manipulated or out-of-sync snapshot and acts on it.
Impact: Mispriced assets, bypassed checks, distorted accounting, and downstream economic loss can follow, especially where other contracts trust the read as a stable source of truth.
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, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Read-time trust boundaries can affect authorization decisions in dependent logic. |
| V15 — Secure Coding and Architecture | The bug is an architectural flaw in how read paths interact with external calls. | |
| Recommendation — Review value-dependent decisions so untrusted reads cannot steer privileged actions. Redesign read paths to avoid external callbacks before critical values are finalized. | ||
| MITRE ATT&CK | T1211 — Exploitation for Defense Evasion | Attackers abuse execution flow to conceal manipulation from normal checks. |
| Recommendation — Map callback-driven manipulation to ATT&CK and hunt for unexpected control-flow recursion. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure coding and validation practices directly address contract logic flaws. |
| Recommendation — Embed security review and testing for callback-driven logic paths in application security. | ||
| SLSA | SLSA — Supply-chain Levels for Software Artifacts | Build and verification discipline helps ensure deployed contract code matches reviewed intent. |
| Recommendation — Verify released artifacts and contract builds so reviewed logic is the logic deployed. | ||
Practitioner Guidance
What to watch for: Treat any read that can touch untrusted code as a control point, not a harmless query. The highest-risk cases are price checks, balance-derived guards, and risk thresholds that are consumed immediately by trading, liquidation, or routing logic.
Practitioner takeaway: If a read can be influenced by external execution, validate the entire dependency chain, not just the function marked view.