Detecting Reentrancy Vulnerabilities: A 12-Step Workflow with Slither and Foundry
Shattered.io published a 12-step workflow for catching reentrancy bugs in Solidity using Slither and Foundry.
Caleb North·updated August 27, 2026

The guide builds a vulnerable vault contract from scratch, runs a static-analysis pass against it, writes a working proof-of-concept attacker contract inside a Foundry test, patches the bug three different ways, and finally wires Slither into GitHub Actions so regressions fail the build. For teams shipping DeFi in 2026, the audit backlog is not the issue — repeat exploits are.
The reentrancy pattern, 2025–2026
The bug is external calls made before internal state updates. The incident list traces the same shape across every major event. GMX V1 lost $42 million in July 2025 when executeDecreaseOrder accepted an attacker-controlled refund recipient and handed over control mid-transaction. Yearn's yETH pool lost roughly $9 million on November 30, 2025 after an attacker minted 235 septillion yETH from 16 wei of input. FutureSwap lost $74,000 in January. An unverified mainnet contract lost about $11,000 in March. All reentrancy. All covered by the checks-effects-interactions pattern Solidity courses have taught for a decade. Per OWASP's 2026 Smart Contract Top 10, reentrancy remains one of the most common root causes of exploited code. Blockeden's 2026 audit landscape report attributes $953.2 million in losses to access-control bugs, $63.8 million to logic errors, and $35.7 million specifically to reentrancy. Reentrancy is not the largest category. It is the most reproducible.
What the 12-step workflow actually executes
Slither runs without a test harness. It flags the external call, the missing state write before it, and the unprotected function. Foundry turns the bug into a red-green test: deploy the vulnerable vault, deploy an attacker contract whose fallback re-enters withdraw before balances decrement, assert the attacker drained more than they deposited. The tutorial then patches the contract three ways — a reentrancy guard, a mutex, and strict checks-effects-interactions ordering — each with its own passing test case. The exploit test fails first, passes after the fix. That is the audit no human reviewer can replace.
Operational guardrails before merge
A static analyzer run only on a senior auditor's laptop is not a security control. Wire slither. into GitHub Actions on every pull request. Add a Foundry fuzz run targeting every function that performs an external call. Require both. New contributors cannot reintroduce the bug if CI fails the PR before merge. Even teams scaling through the Founder Institute's startup hub model carry the same exposure when their DeFi product ships; the tooling chain matters more than headcount.
Checklist — non-negotiable before merge:
- Slither pass clean on every PR. No warnings ignored.
- Foundry exploit test against every external-call function.
- Reentrancy guard on every state-mutating entrypoint.
- CI fails the build on any regression. No override without a second reviewer.