Read-Only Reentrancy

The core vulnerability is a temporary inconsistency between a contract's internal accounting and its external view. Key phases:

• Phase 1: An update function (e.g., transferring tokens) begins but hasn't written the new state.
• Phase 2: A view function (e.g., balanceOf) is called reentrantly. It returns the old, pre-update state.
• Phase 3: An external protocol relying on this outdated data makes an incorrect decision, such as approving an undercollateralized loan.

The primary defense is strict adherence to the CEI pattern:

1. Checks: Validate all conditions (e.g., sufficient balance).
2. Effects: Update all internal state variables first (e.g., deduct balances).
3. Interactions: Make external calls last (e.g., transfer tokens). By finalizing state before any external interaction, you eliminate the window where view functions can return stale data. This must be combined with reentrancy guards on state-changing functions.

Identifying read-only reentrancy requires specialized analysis because it spans multiple contracts. Key tools and methods include:

• Static Analyzers: Slither and MythX can detect potential state inconsistencies after external calls.
• Formal Verification: Tools like Certora can prove that a contract's state is consistent at all external view entry points.
• Fuzzing & Invariant Testing: Frameworks like Foundry can test that certain invariants (e.g., total collateral >= total debt) hold even during reentrant calls.

Read-only reentrancy often targets price oracles or liquidity checks. A common attack vector:

• Manipulate a DEX pool's spot price via a large, reentrant swap during a state update.
• A lending protocol's oracle (e.g., using getReserves()) reads the manipulated price.
• The attacker borrows assets at an incorrect exchange rate. This differs from flash loan oracle attacks as it exploits the timing of the state read, not just capital size.

The attack exploits the gap between a contract's actual internal state and the view of that state presented to external, non-state-modifying (view) functions. An attacker reenters a view function during a state-changing operation, causing it to return data based on an inconsistent, mid-update state.

• Example: A lending protocol's getAccountLiquidity() function might read a user's collateral balance from a vault that is currently being withdrawn, incorrectly reporting high liquidity and allowing unsafe borrowing.

Standard reentrancy guards (e.g., nonReentrant modifiers) protect functions that modify state, but they do not lock view or pure functions. An attacker can call these "read-only" functions during a callback, effectively bypassing the intended protection.

• Mechanism: 1) Attacker triggers a state-changing function (e.g., withdraw). 2) During its execution, a callback is made to the attacker's contract. 3) The attacker's contract reenters the vulnerable protocol via a view function, which reads corrupted state. 4) Based on this false data, the attacker executes a harmful action in a separate, connected system.

The primary danger is cross-contract manipulation. The corrupted read is often used by an external, integrated protocol (e.g., a DEX, oracle, or another lending market) to make a critical decision.

• Real-World Vector: The attacker corrupts the reported price of an LP token in Vault A. A separate lending protocol, TrustedProtocol B, uses this price to determine collateral value. TrustedProtocol B, seeing inflated collateral, permits an oversized, undercollateralized loan to the attacker.

The fundamental defense is adhering to Checks-Effects-Interactions (CEI) and ensuring state consistency before any external call. Specific mitigations include:

• Internal State Consistency: Complete all state updates (Effects) before making external calls (Interactions).
• Reentrancy Guards on View Functions: Apply guards to sensitive view functions that are called by external integrators, treating them as potentially stateful.
• Using Private/Internal Functions: For sensitive state reads called during state changes, use private or internal visibility to prevent external reentry.

Identifying read-only reentrancy requires static analysis and careful review of cross-contract dependencies.

• Static Analysis Tools: Advanced tools like Slither and MythX can detect patterns where view functions are called after external calls.
• Code Review Focus: Auditors must trace all view functions used by external protocols, especially those reading balances, prices, or liquidity metrics. Any state change that makes an external call before finalizing its own state is a potential vector.

The vulnerability was formally identified and named in a 2022 research post by ChainSecurity. It represents an evolution of classical reentrancy, exploiting the composable nature of DeFi.

• Notable Incidents: While no single massive exploit is solely attributed to it, the pattern has been identified in several high-value protocols during audits, leading to critical fixes. It underscores the security risks inherent in DeFi composability, where the security of one protocol depends on the state integrity of another.

The foundational defense against all reentrancy. It mandates a strict execution order:

• Checks: Validate all conditions and inputs.
• Effects: Update the contract's internal state before any external calls.
• Interactions: Perform external calls last. This ensures the contract's state is finalized and consistent before reentrancy is possible, making read-only reentrancy attempts see the correct, updated state.

Design view/pure functions to be resilient to intermediate state. Key techniques include:

• Using a single SLOAD for a state variable and storing it in a local memory variable for calculations.
• Avoiding logic that performs comparisons between two separate state reads that could be inconsistent mid-transaction.
• Documenting that view functions may return transient, in-progress states during a transaction's execution.

Applying a non-reentrant modifier (like OpenZeppelin's ReentrancyGuard) to any function that makes an external call. While primarily for classic reentrancy, it also prevents the interleaving of transactions that create the inconsistent state read-only attacks depend on. This is a critical mitigation for functions that update shared state later read by view functions.

Implement low-level locking mechanisms for critical shared resources. This can involve:

• A locked state variable that must be checked before accessing a sensitive vault or oracle.
• Ensuring that any function reading a dependent value also checks the lock status of its source. This explicitly serializes access, preventing the race condition where a view function reads a partially updated dependency.

Decouple systems to minimize trust assumptions. Strategies include:

• Using internal balances (like ERC-4626 shares) instead of direct asset queries for calculations.
• Designing oracles and price feeds to be self-contained and not reliant on the state of other potentially reentrant protocols.
• Treating external view calls as untrusted inputs and sanitizing or validating them when used.

In July 2022, a read-only reentrancy vulnerability was exploited, allowing an attacker to manipulate Aave's health factor calculation by re-entering via Lido's stETH rebasing mechanism.

• Mechanism: The attacker used a flash loan and a malicious contract to call stETH during an Aave liquidation, tricking Aave into seeing an incorrect, inflated collateral balance.
• Outcome: The vulnerability was white-hat reported and fixed before significant funds were lost, but it demonstrated the critical, cross-protocol nature of the threat.

Preventing read-only reentrancy requires moving beyond simple nonReentrant modifiers.

• Best Practices:
  • Checks-Effects-Interactions (CEI): Strictly enforce this pattern, even for view/pure functions called externally.
  • State Consistency Checks: Add internal guards that revert if critical invariants are violated mid-transaction.
  • Static Analysis: Use tools like Slither or Scribble to detect potential state inconsistencies after external calls.

A classic example where the Balancer Vault was vulnerable. The joinPool and exitPool functions performed an external callback to the caller before updating the Vault's internal token balances.

• The Flaw: A malicious pool contract could re-enter the Vault during this callback. A subsequent getPoolTokens call would return stale, pre-update balances, enabling price manipulation.
• The Fix: Balancer moved the callback to after all internal state updates, restoring the CEI pattern.

Specialized tools are essential for finding these complex vulnerabilities.

• Slither: A static analysis framework that can detect read-only reentrancy by identifying functions that perform external calls while a contract is in an inconsistent state.
• Fuzzing & Formal Verification: Tools like Echidna or Certora Prover can be used to formally specify and test that critical state invariants hold across all execution paths, including reentrant ones.