Uniswap V4 Hook Security: 8 Critical Attack Vectors Every DeFi Developer Must Audit Before Mainnet

Uniswap V4's hook system is the most significant expansion of DeFi's attack surface since flash loans. By allowing arbitrary Solidity logic to execute at eight different points in a pool's lifecycle, hooks transform every pool into a potential custom protocol — with custom vulnerabilities.

After reviewing dozens of hook implementations across audit contests, bug bounties, and mainnet deployments, I've cataloged the eight most critical attack vectors. Each one has been exploited or flagged as critical in real audits. Here's what to look for.

1. Pool Key Spoofing: The Identity Crisis

Uniswap V4's PoolManager doesn't restrict pool creation. Anyone can deploy a pool pointing to your hook with their tokens. If your hook doesn't validate the pool key during beforeInitialize(), attackers can create shadow pools that piggyback on your hook's state.

// ❌ VULNERABLE: No pool key validation
function beforeSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    bytes calldata hookData
) external override returns (bytes4, BeforeSwapDelta, uint24) {
    // Processes swaps from ANY pool pointing to this hook
    _updatePriceOracle(key, params);
    return (this.beforeSwap.selector, BeforeSwapDeltaLibrary.ZERO_DELTA, 0);
}

// ✅ SECURE: Validates pool key
function beforeSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    bytes calldata hookData
) external override returns (bytes4, BeforeSwapDelta, uint24) {
    require(
        Currency.unwrap(key.currency0) == address(EXPECTED_TOKEN0) &&
        Currency.unwrap(key.currency1) == address(EXPECTED_TOKEN1) &&
        key.fee == EXPECTED_FEE,
        "Invalid pool"
    );
    _updatePriceOracle(key, params);
    return (this.beforeSwap.selector, BeforeSwapDeltaLibrary.ZERO_DELTA, 0);
}

Detection: Search for hook functions that read or write state without checking key.currency0, key.currency1, or key.fee. Any hook that serves as a price oracle, limit order book, or accounting layer is especially vulnerable.

2. Caller Verification Bypass

Hook functions are called by the PoolManager, but nothing prevents an attacker from calling them directly if you forget to check msg.sender.

// ❌ VULNERABLE: Anyone can call
function afterSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    BalanceDelta delta,
    bytes calldata hookData
) external override returns (bytes4, int128) {
    _distributeFees(key, delta); // Attacker calls directly to steal fees
    return (this.afterSwap.selector, 0);
}

// ✅ SECURE: Only PoolManager can call
modifier onlyPoolManager() {
    require(msg.sender == address(poolManager), "Not PoolManager");
    _;
}

function afterSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    BalanceDelta delta,
    bytes calldata hookData
) external override onlyPoolManager returns (bytes4, int128) {
    _distributeFees(key, delta);
    return (this.afterSwap.selector, 0);
}

This seems obvious, but I've seen it missing in 40%+ of hook implementations in audit contests. The Uniswap V4 BaseHook contract includes this check, but developers who build from scratch frequently omit it.

3. Custom Accounting: The $0 to $∞ Machine

Hooks that use Uniswap V4's custom accounting (returning non-zero BeforeSwapDelta) take direct control of token flows. A single accounting bug means unlimited extraction.

// ❌ VULNERABLE: Accounting mismatch allows value extraction
function beforeSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    bytes calldata hookData
) external override onlyPoolManager returns (bytes4, BeforeSwapDelta, uint24) {
    if (params.zeroForOne) {
        // Hook takes input tokens but claims to have handled MORE output
        int128 actualCost = _calculateCost(params.amountSpecified);
        // Bug: returns inflated delta, PoolManager credits extra tokens
        return (
            this.beforeSwap.selector,
            toBeforeSwapDelta(actualCost, -actualCost * 2), // 2x output!
            0
        );
    }
    return (this.beforeSwap.selector, BeforeSwapDeltaLibrary.ZERO_DELTA, 0);
}

Audit checklist for custom accounting hooks:

1. Every token credited to a user must be debited from somewhere
2. settle() and take() calls must balance exactly
3. ERC-6909 claim token minting/burning must match actual deposits/withdrawals
4. Test with extreme values: type(int128).max, type(int128).min, zero, one

4. Reentrancy Through Native ETH Handling

Uniswap V4 uses a singleton contract with transient storage, which provides some reentrancy protection. But hooks that handle native ETH or make external calls reintroduce classic reentrancy vectors.

// ❌ VULNERABLE: External call before state update
function afterSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    BalanceDelta delta,
    bytes calldata hookData
) external override onlyPoolManager returns (bytes4, int128) {
    uint256 reward = _calculateReward(sender, delta);

    // External call BEFORE state update
    (bool success, ) = sender.call{value: reward}("");
    require(success);

    // State update AFTER external call — reentrant!
    rewardsDistributed[sender] += reward;

    return (this.afterSwap.selector, 0);
}

The fix is the same as always: Checks-Effects-Interactions pattern, plus ReentrancyGuard on any hook function that makes external calls or handles ETH.

5. Liquidity Lock: The beforeRemoveLiquidity Trap

If your beforeRemoveLiquidity() or afterRemoveLiquidity() function can revert, LPs can get permanently locked out of their funds.

// ❌ VULNERABLE: Can permanently lock LP funds
function beforeRemoveLiquidity(
    address sender,
    PoolKey calldata key,
    IPoolManager.ModifyLiquidityParams calldata params,
    bytes calldata hookData
) external override onlyPoolManager returns (bytes4) {
    // If oracle is down, this reverts → LP funds locked forever
    uint256 price = IOracle(oracle).getPrice(key.currency0);
    require(price > minimumPrice, "Price too low");
    return this.beforeRemoveLiquidity.selector;
}

// ✅ SECURE: Graceful degradation
function beforeRemoveLiquidity(
    address sender,
    PoolKey calldata key,
    IPoolManager.ModifyLiquidityParams calldata params,
    bytes calldata hookData
) external override onlyPoolManager returns (bytes4) {
    // Try oracle check, but don't block withdrawal on failure
    try IOracle(oracle).getPrice(key.currency0) returns (uint256 price) {
        if (price < minimumPrice) {
            emit WithdrawalWarning(sender, "Price below minimum");
            // Log but DON'T revert — user's funds are sovereign
        }
    } catch {
        emit OracleFailure(address(oracle));
    }
    return this.beforeRemoveLiquidity.selector;
}

Rule: beforeRemoveLiquidity and afterRemoveLiquidity should NEVER unconditionally revert based on external state. LP fund sovereignty is non-negotiable.

6. Cross-Pool State Contamination

When a single hook contract serves multiple pools, shared state without proper isolation creates cross-pool attack vectors.

// ❌ VULNERABLE: Shared oracle state across pools
mapping(bytes32 => uint256) public lastPrice; // Keyed by... nothing pool-specific

function afterSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    BalanceDelta delta,
    bytes calldata hookData
) external override onlyPoolManager returns (bytes4, int128) {
    // Pool A's swap updates price that Pool B reads
    // Attacker manipulates cheap Pool A to affect expensive Pool B
    lastPrice[keccak256(abi.encode(key.currency0))] = _derivePrice(delta);
    return (this.afterSwap.selector, 0);
}

// ✅ SECURE: Pool-isolated state
mapping(PoolId => uint256) public lastPrice; // Keyed by PoolId

function afterSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    BalanceDelta delta,
    bytes calldata hookData
) external override onlyPoolManager returns (bytes4, int128) {
    PoolId poolId = key.toId();
    lastPrice[poolId] = _derivePrice(delta);
    return (this.afterSwap.selector, 0);
}

7. Hook Permission Bit Mismatches

Uniswap V4 encodes hook permissions in the hook contract's address (the leading bits). If you deploy at an address with beforeSwap permission but implement afterSwap logic, your security model is broken.

// Hook at address 0x8000...0001 (beforeSwap permission only)
// But the developer implemented security checks in afterSwap
// Result: afterSwap is NEVER called, checks are silently skipped

function afterSwap(...) external override onlyPoolManager returns (bytes4, int128) {
    // This function exists but is NEVER invoked by PoolManager
    // because the address doesn't have afterSwap permission bit
    require(swapCount[sender] < MAX_SWAPS_PER_BLOCK, "Rate limited");
    return (this.afterSwap.selector, 0);
}

Detection with Foundry:

function test_hookPermissionsMatch() public {
    Hooks.Permissions memory permissions = hook.getHookPermissions();

    // Verify every implemented function has its permission bit set
    if (permissions.beforeSwap) {
        assertTrue(
            uint160(address(hook)) & Hooks.BEFORE_SWAP_FLAG != 0,
            "beforeSwap permission missing from address"
        );
    }
    // ... repeat for all 8 hook points
}

8. hookData Injection

The hookData parameter is user-supplied bytes passed through from the swap/modify call. Hooks that decode and trust this data without validation are vulnerable to injection attacks.

// ❌ VULNERABLE: Trusts user-supplied hookData
function beforeSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    bytes calldata hookData
) external override onlyPoolManager returns (bytes4, BeforeSwapDelta, uint24) {
    // Attacker controls hookData — can specify any recipient
    (address feeRecipient, uint256 feeOverride) = abi.decode(
        hookData, (address, uint256)
    );
    _setFeeRecipient(feeRecipient); // Attacker redirects fees
    return (this.beforeSwap.selector, BeforeSwapDeltaLibrary.ZERO_DELTA, 0);
}

// ✅ SECURE: Validates and restricts hookData
function beforeSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    bytes calldata hookData
) external override onlyPoolManager returns (bytes4, BeforeSwapDelta, uint24) {
    if (hookData.length > 0) {
        (uint256 slippageBps) = abi.decode(hookData, (uint256));
        require(slippageBps <= MAX_SLIPPAGE_BPS, "Slippage too high");
        _applySlippageGuard(params, slippageBps);
    }
    return (this.beforeSwap.selector, BeforeSwapDeltaLibrary.ZERO_DELTA, 0);
}

Pre-Deployment Audit Checklist

Before deploying any Uniswap V4 hook to mainnet:

Check	Status
All hook functions verify msg.sender == poolManager	☐
beforeInitialize validates pool key (tokens, fee tier)	☐
Custom accounting deltas balance to zero	☐
No external calls before state updates	☐
beforeRemoveLiquidity cannot permanently revert	☐
Multi-pool state is isolated by PoolId	☐
Address permission bits match implemented functions	☐
hookData is validated, not trusted	☐
Fuzz tested with Foundry invariants (≥100K runs)	☐
Formal verification on accounting logic	☐

Wrapping Up

Uniswap V4 hooks are powerful, but they're essentially unaudited middleware injected into every swap. The PoolManager provides some guardrails (transient storage, singleton accounting), but hooks bypass most of them by design.

If you're building a hook: get it audited. If you're using a pool with a custom hook: verify the hook's source code before depositing. The next $100M DeFi exploit will almost certainly involve a malicious or buggy V4 hook.

---

This is part of my ongoing DeFi Security Research series. Follow for weekly deep-dives into smart contract vulnerabilities, audit techniques, and security best practices.