Reentrancy

Reentrancy detection

When this applies

Trigger on any of:

• External calls via call, delegatecall, staticcall, transfer, send
• safeTransferFrom / onERC721Received / onERC1155Received callbacks
• ERC-777 tokensReceived / tokensToSend hooks
• Cross-contract calls preceding state writes
• View functions that read state which is mid-update (read-only reentrancy)
• Custom token callbacks, governance vote-cast hooks, flash-loan callbacks
• Compound/Aave-style accounting that updates user balances after external transfers

Detection patterns

Classic reentrancy (CRITICAL / HIGH)

function withdraw() external {
    uint256 amt = balance[msg.sender];
    (bool ok,) = msg.sender.call{value: amt}("");   // ← external call
    require(ok);
    balance[msg.sender] = 0;                         // ← state update AFTER call
}

Signal: state mutation after external call. CEI (Checks-Effects-Interactions) violated.

Cross-function reentrancy (HIGH)

Two functions sharing state where one calls externally and the other reads/mutates the same state. Attacker re-enters via the second function.

Cross-contract reentrancy (HIGH)

Contract A updates state, calls B; B calls back into a different contract C that reads A's stale state.

Read-only reentrancy (HIGH — frequently missed)

Victim contract reads getReserves() / getPrice() from a pool mid-callback, before the pool finalizes its state. Example: Curve pools, Balancer vaults, Uniswap V2 mid-removeLiquidity.

// Pool callback hits this view function before pool state is consistent.
function priceOf(address token) external view returns (uint256) {
    return pool.getVirtualPrice();   // ← stale during reentrant call
}

ERC-777 / ERC-721 hook reentrancy (HIGH)

_safeTransfer calls onERC721Received on the recipient — if recipient is a contract, it can re-enter.

Severity rubric

| Pattern | Severity | Notes | |---|---|---| | Funds-draining classic reentrancy | Critical | Direct loss of funds, no preconditions | | Cross-function with shared balance state | High | Requires specific call sequence | | Read-only reentrancy on price/oracle read | High | Common pattern, often missed | | Reentrancy gated by onlyOwner / trusted role | Medium | Centralization-bounded | | ERC-777 hook with no state-after-call writes | Low | Defense-in-depth issue | | Single-actor self-reentrancy with no value flow | Info | |

Remediation patterns

1. CEI ordering — effects before interactions, always.
2. nonReentrant modifier (ReentrancyGuard from OpenZeppelin). Add per-function.
3. For read-only reentrancy — guard the view function too, or use a separate "settled price" cache that only updates outside callbacks. Curve's solution: withdraw_admin_fees lock, Balancer's ensureNotInVaultContext.
4. Pull over push payments — let users withdraw rather than pushing transfers.
5. Token whitelist — avoid ERC-777 and rebasing tokens in untested paths.

False-positive notes

• A function that uses nonReentrant from a known-good library and only calls trusted contracts is generally safe — note it but don't flag as Critical.
• transfer (2300 gas) blocks classic reentrancy but is brittle on L2s with higher base gas costs — flag as a separate issue, not as reentrancy resolved.
• Reentrancy into a function that only reads (no state writes downstream) and that read isn't used in a check — Info, not High.

Related

• [[oracle-manipulation]] — read-only reentrancy often is an oracle issue
• [[token-compatibility]] — ERC-777 / rebasing tokens widen the attack surface
• [[delegatecall-risks]] — delegatecall through untrusted target = reentrancy + storage corruption combo

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: omermaksutii
• Source: omermaksutii/RugProof
• License: MIT
• Homepage: https://omermaksutii.github.io/RugProof

Install and usage instructions live in the source repository linked above.