This guide provides a comprehensive analysis\u00a0of reentrancy vulnerabilities with\u00a0practical, executable examples for each attack type. Learn\u00a0how different reentrancy patterns work\u00a0and how to identify them in real\u00a0protocols.<\/p>\n
Reentrancy occurs\u00a0when an external contract call\u00a0recursively calls back into the calling function\u00a0before it completes execution. During\u00a0external calls, control passes\u00a0to the recipient contract, which\u00a0can execute arbitrary code. If state updates happen after<\/strong>\u00a0the external call, attackers can re-enter the function\u00a0and drain funds.<\/p>\n Reentrancy hacks\u00a0are still happening today. For\u00a0a comprehensive list of historical reentrancy exploits, see\u00a0pcaversaccio’s reentrancy-attacks repository<\/a>.<\/p>\n Any\u00a0contract that makes external calls is potentially\u00a0vulnerable, especially those related to withdrawal mechanisms, DeFi protocols, and cross-chain bridges.<\/p>\n Follow\u00a0the Checks-Effects-Interactions (CEI) pattern: perform checks, update state, and only then make external calls. This\u00a0ordering prevents exploitation of inconsistent states.<\/p>\n ReentrancyGuard prevents single-contract reentrancy but not cross-contract attacks. Use pull payment patterns and minimise external calls for better security.<\/p>\n Wake<\/a>‘s Python-based framework\u00a0includes reentrancy detection through static analysis and testing patterns, identifying vulnerabilities before deployment.<\/p>\n Key attack vectors include:<\/p>\n Every external call is\u00a0a potential vulnerability point.<\/strong><\/p>\n Reentrancy ranges from simple recursive calls to complex multi-contract exploits. Each type requires different defensive strategies. Developers must consider all attack possibilities during development. Let’s take a closer look at the mechanics of these critical vulnerabilities.<\/p>\n In a single-function reentrancy<\/a>, attackers recursively call the same function during external calls. It is most common in withdrawal functions that send ETH before updating balances.<\/p>\n Example vulnerability:<\/strong><\/p>\n Attack steps:<\/strong><\/p>\n Prevention:<\/strong>\u00a0Update state before external calls following the CEI pattern.<\/p>\n Cross-function reentrancy<\/a> exploits multiple functions within one contract. It gets dangerous when developers protect individual functions but miss their interactions.<\/p>\n Example vulnerability:<\/strong><\/p>\n Attack vector:<\/strong>\u00a0Attacker re-enters through\u00a0unprotected\u00a0 Prevention:<\/strong>\u00a0Apply\u00a0reentrancy guards to all state-modifying functions or use CEI pattern consistently.<\/p>\n As the name implies, cross-chain reentrancy<\/a> manipulates cross-chain messaging to mint duplicate tokens across chains. This makes it critical for bridge implementations.<\/p>\n Vulnerability pattern:<\/strong>\u00a0Cross-chain contracts\u00a0often increment counters or update state after\u00a0external calls like\u00a0 Real impact:<\/strong>\u00a0Same\u00a0 Prevention:<\/strong><\/p>\n Cross-contract reentrancy<\/a> spans\u00a0multiple contracts, bypassing Attack\u00a0pattern:<\/strong>\u00a0Contract A protected with\u00a0ReentrancyGuard calls Contract B. During Contract A’s external call, attacker re-enters through Contract B’s unprotected functions, manipulating shared state.<\/p>\n Example\u00a0scenario:<\/strong>\u00a0Vault contract with ReentrancyGuard uses\u00a0separate Token contract. Attacker re-enters through Token\u00a0contract’s transfer function during Vault’s withdrawal process.<\/p>\n Prevention:<\/strong>\u00a0Implement consistent reentrancy protection across all interacting contracts and follow CEI pattern in\u00a0contract interactions.<\/p>\n Read-only reentrancy<\/a> exploits view functions during\u00a0state transitions. This makes it critical in DeFi protocols relying on price oracles.<\/p>\n Vulnerability mechanism:<\/strong>\u00a0View functions appear safe but can\u00a0return inconsistent data during state transitions. Attackers exploit\u00a0this window to get incorrect price calculations.<\/p>\n Example\u00a0scenario:<\/strong><\/p>\n During\u00a0external calls,\u00a0totalStake\u00a0might\u00a0be updated while\u00a0totalTokens\u00a0remains unchanged, creating price manipulation\u00a0opportunities.<\/p>\n Prevention:<\/strong>\u00a0Avoid view functions dependent on mutable state during external calls. Implement state consistency checks.<\/p>\n In a flash loan reentrancy<\/a>, attackers manipulate token balances during loan\u00a0execution by exploiting improper balance verification. Creates “side entrance” attacks where attackers use\u00a0flash loans to temporarily inflate balances, bypass\u00a0checks, then extract funds through different withdrawal mechanisms.<\/p>\n Common pattern:<\/strong>\u00a0Flash loan increases\u00a0user’s balance, triggering withdrawal logic\u00a0that doesn’t account for the temporary balance inflation.<\/p>\n In an\u00a0ERC-721 reentrancy<\/a>, the Attack vector:<\/strong>\u00a0Malicious contracts can re-enter during\u00a0How to prevent reentrancies?<\/h2>\n
Identifying reentrancy vulnerabilities<\/strong><\/h2>\n
\n
Types of reentrancy attacks<\/strong><\/h2>\n
Single-function reentrancy<\/strong><\/h3>\n
function\u00a0withdraw()\u00a0public\u00a0{\n\t\tuint256\u00a0amount\u00a0=\u00a0balances[msg.sender];\n\t\t(bool\u00a0success,\u00a0)\u00a0=\u00a0msg.sender.call{value:\u00a0amount}("");\n\t\trequire(success,\u00a0"Failed\u00a0to\u00a0send\u00a0Ether");\n\t\tbalances[msg.sender]\u00a0=\u00a00;\u00a0\/\/\u00a0State\u00a0updated\u00a0after\u00a0external\u00a0call\n}<\/code><\/pre>\n\n
withdraw()<\/code><\/li>\nwithdraw()<\/code><\/li>\nCross-function reentrancy<\/strong><\/h3>\n
contract\u00a0Vault\u00a0is\u00a0ReentrancyGuard\u00a0{\n\t\tfunction\u00a0transfer(address\u00a0to,\u00a0uint256\u00a0amount)\u00a0public\u00a0{\n\t\t\t\t\/\/\u00a0No\u00a0reentrancy\u00a0protection\u00a0here\n\t\t\t\tif\u00a0(balances[msg.sender]\u00a0>=\u00a0amount)\u00a0{\n\t\t\t\t\t\tbalances[to]\u00a0+=\u00a0amount;\n\t\t\t\t\t\tbalances[msg.sender]\u00a0-=\u00a0amount;\n\t\t\t\t}\n\t\t}\n\t\tfunction\u00a0withdraw()\u00a0public\u00a0nonReentrant\u00a0{\n\t\t\t\tuint256\u00a0amount\u00a0=\u00a0balances[msg.sender];\n\t\t\t\t(bool\u00a0success,\u00a0)\u00a0=\u00a0msg.sender.call{value:\u00a0amount}("");\n\t\t\t\trequire(success,\u00a0"Failed\u00a0to\u00a0send\u00a0Ether");\n\t\t\t\tbalances[msg.sender]\u00a0=\u00a00;\n\t\t}\n}<\/code><\/pre>\ntransfer()<\/code>\u00a0during\u00a0withdraw()<\/code>\u00a0external call, manipulating balances before the withdrawal completes.<\/p>\nCross-chain reentrancy<\/strong><\/h3>\n
_safeMint()<\/code>. If an attacker re-enters during\u00a0the external call, they can trigger the same cross-chain event multiple times before state\u00a0updates.<\/p>\ntokenId<\/code>\u00a0minted on multiple chains, breaking\u00a0bridge accounting and creating phantom tokens.<\/p>\n\n
Cross-contract reentrancy<\/strong><\/h3>\n
ReentrancyGuard<\/code>. This means it requires comprehensive interaction analysis.<\/p>\nRead-only reentrancy<\/strong><\/h3>\n
function\u00a0getCurrentPrice()\u00a0public\u00a0view\u00a0returns\u00a0(uint256)\u00a0{\n\t\tif\u00a0(totalTokens\u00a0==\u00a00)\u00a0return\u00a010e18;\n\t\treturn\u00a0(totalTokens\u00a0*\u00a010e18)\u00a0\/\u00a0totalStake;\n}<\/code><\/pre>\nProtocol-specific vulnerabilities<\/strong><\/h2>\n
Flash loan reentrancy<\/strong><\/h3>\n
ERC-721 reentrancy<\/strong><\/h3>\n
onERC721Received<\/code>\u00a0callback enables attacks during NFT transfers. Critical for marketplaces and staking contracts\u00a0where NFT transfers trigger state changes or\u00a0payments.<\/p>\n_safeMint<\/code>\u00a0or\u00a0safeTransferFrom\u00a0calls, manipulating contract state before NFT transfer completes.<\/p>\nERC-777 reentrancy<\/strong><\/h3>\n