Educational Content
This is an educational case study based on common vulnerability patterns, not a specific client engagement.
Anatomy of a Reentrancy Vulnerability
Context
This educational case study walks through a common reentrancy pattern found in DeFi vault contracts. It is not based on a specific client engagement but represents a composite of real-world patterns our auditors encounter. We publish this to help developers understand what our audit process looks like from the inside.
The Pattern
A staking vault allows users to deposit ETH and withdraw at any time. The withdraw() function sends ETH using call{value: amount}("") before updating the user's internal balance. This violates the checks-effects-interactions pattern and allows a malicious contract to re-enter withdraw() via its receive() fallback, draining the vault in a single transaction.
How We Find It
Our audit process combines manual line-by-line review with automated tools. Static analyzers flag the state-update-after-external-call pattern, but manual review is essential to understand whether the reentrancy is actually exploitable in context. We construct a proof-of-concept in Foundry to confirm exploitability and measure the maximum impact.
The Fix
The recommended fix is straightforward: move the balance update before the external call (checks-effects-interactions) and add OpenZeppelin's ReentrancyGuard as defense-in-depth. We verify the fix in a follow-up remediation review to confirm the vulnerability is fully resolved.
Takeaway
Reentrancy remains one of the most dangerous and persistent vulnerability classes in Solidity. Despite widespread awareness since the 2016 DAO hack, it continues to appear in new forms -- cross-function, cross-contract, and read-only variants. A professional audit catches these patterns before deployment.
Protect your protocol
Request an audit to find vulnerabilities before attackers do.
Request an Audit