Reentrancy

Reentrancy Playbook

Variants

1. Classic — external call before state update (The DAO)
2. Cross-function — A calls out, reentered into B which reads/writes A's state
3. Read-only — view function reads stale state during reentrancy, consumed by a second contract making decisions
4. Cross-contract — same attack pattern across protocol boundaries
5. ERC777 / ERC1155 hook — onERC*Received callback re-enters

Audit steps

1. solidity_scan_file flags every .call{value:...} and delegatecall
2. For each hit, check:
   • Is there a state write BEFORE the external call?
   • Is ReentrancyGuard's nonReentrant modifier applied?
   • Does it follow checks-effects-interactions?
3. Trace call graph — if any function the call target can invoke reads or writes the same state slot, that's a reentrancy chain.

PoC via Foundry

foundry_reentrancy_test(target="Vault", function="withdraw", target_path="src/Vault.sol")

Then:

cp generated.t.sol /workspace/foundry/test/
cd /workspace/foundry && forge test -vvv --match-contract Test_withdraw

Success criteria

The attacker contract balance grows by more than its initial deposit after the attack transaction. The Foundry test should assert this.

CVSS

• Direct fund drain: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H = 10.0
• Read-only with downstream impact: 8.1-9.1 depending on impact

Known exemplars

• The DAO (2016)
• Lendf.Me (2020, ERC777 hook reentrancy, $25M)
• Cream Finance (2021)
• Rari Capital (2022)
• Curve pool read-only reentrancy (2023)