HeisenbergHook Fee Path Hijack — Unrestricted `poolKey` overwrite + permissionless `processFees`/`processBurn`

Source & credit. Original research reproduction (not from DeFiHackLabs). Standalone Foundry PoC, offline anvil_state.json, and full write-up: 2026-05-HeisenbergHook_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/logic/incorrect-state-transition · vuln/defi/fee-manipulation · vuln/logic/missing-check · vuln/input-validation/missing

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. The fork is served offline from the bundled anvil_state.json (local anvil replays Ethereum state at block 25059345), so no public RPC is required. Full verbose trace: output.txt. Verified vulnerable source: src_HeisenbergHook.sol.

Key info#

TL;DR#

1. HeisenbergHook is a Uniswap v4 hook for the $HEIST / ETH pool. Sell-side fees accumulate as pendingFeeHEIST (5,261 HEIST pre-attack); buy-side fees split into treasury / platform / pendingBurnETH (0.158 ETH earmarked for buy-and-burn).

2. _beforeInitialize validates currency0 == ETH and currency1 == HEIST, then always writes poolKey = key and sets poolInitialized = true (src_HeisenbergHook.sol:282-289). The poolInitialized flag is never used to reject a second initialize.

3. processFees() / processBurn() are permissionless and swap the entire fee inventory against poolKey with no slippage bounds (:679-703).

4. The attacker CREATE-deploys a Morpho 10 WETH flash-loan contract that:

   • initializes a new thin ETH/HEIST pool with the same hook but fee=0 / different tickSpacing (overwriting poolKey),
   • adds full-range liquidity,
   • calls processFees / processBurn so the hook dumps inventory through the attacker's LP,
   • removes liquidity + sells residual HEIST, repays Morpho, keeps 0.425919592403168892 ETH.

Background#

HeisenbergHook implements a "windowed heist" game on Uniswap v4:

• 2% input-side hook fee (50% treasury / 40% platform / 10% buy-and-burn),
• sell fees taken in HEIST and deferred via pendingFeeHEIST until someone calls processFees(),
• buy-and-burn ETH deferred via pendingBurnETH until processBurn(),
• crew membership / heat / LOOT minting on heist windows.

Fee conversion is deliberately public ("anyone can call") so inventory does not sit idle. That design is only safe if the target pool for the conversion is immutable and deep. Here the target is a mutable poolKey set by the first (and every subsequent) beforeInitialize callback.

Uniswap v4 allows many pools that share the same hook address as long as (currency0, currency1, fee, tickSpacing, hooks) differs. The hook is therefore invoked on every such pool's lifecycle events — including initialize of attacker-created sibling pools.

The vulnerable code#

Unrestricted poolKey overwrite#

// sources/HeisenbergHook_bea90e/src_HeisenbergHook.sol:282-289
function _beforeInitialize(address, PoolKey calldata key, uint160) internal override returns (bytes4) {
    if (Currency.unwrap(key.currency0) != address(0)) revert PoolNotSupported();
    if (Currency.unwrap(key.currency1) != address(HEIST)) revert PoolNotSupported();
    poolKey = key;           // always overwrites — no `if (poolInitialized) revert`
    poolInitialized = true;
    emit PoolKeySet(key.toId());
    return BaseHook.beforeInitialize.selector;
}

Permissionless fee dumps against poolKey#

// sources/HeisenbergHook_bea90e/src_HeisenbergHook.sol:679-703
function processFees() external {
    if (pendingFeeHEIST == 0 || !poolInitialized) return;
    uint256 amount = pendingFeeHEIST;
    pendingFeeHEIST = 0;
    bytes memory data = abi.encode(uint256(1), amount); // HEIST -> ETH
    bytes memory result = poolManager.unlock(data);
    uint256 ethReceived = abi.decode(result, (uint256));
    _splitEthFee(ethReceived);
}

function processBurn() external {
    if (pendingBurnETH == 0 || !poolInitialized) return;
    uint256 amount = pendingBurnETH;
    pendingBurnETH = 0;
    bytes memory data = abi.encode(uint256(2), amount); // ETH -> HEIST then burn
    bytes memory result = poolManager.unlock(data);
    uint256 heistReceived = abi.decode(result, (uint256));
    cumulativeBurnedHEIST += heistReceived;
    if (heistReceived > 0) IERC20(address(HEIST)).transfer(DEAD, heistReceived);
}

unlockCallback then performs an exact-input swap on poolKey at the extreme sqrt-price limits (no minOut):

// sources/HeisenbergHook_bea90e/src_HeisenbergHook.sol:712-728 (op == 1)
BalanceDelta delta = poolManager.swap(
    poolKey,
    SwapParams({
        zeroForOne: false,
        amountSpecified: -int256(amount),
        sqrtPriceLimitX96: TickMath.MAX_SQRT_PRICE - 1
    }),
    ""
);

Root cause#

Two composition failures:

1. Mutable fee-routing state. poolKey is the sole routing target for fee conversion, but any address can cause PoolManager to call beforeInitialize on a new ETH/HEIST pool that uses this hook — and the hook trusts that call to rebind routing.

2. Permissionless, slippageless conversion. Once poolKey points at a thin attacker pool, processFees/processBurn dump multi-thousand-HEIST inventory through it. Full-range LP on that pool captures the flow; the real deep pool is bypassed.

Neither bug alone is as severe: a fixed poolKey would make public processFees a standard sandwich surface (bounded by real liquidity); a gated processFees would leave overwrite mostly cosmetic. Together they turn fee inventory into attacker extractable value.

Preconditions#

• Hook already holds large pendingFeeHEIST (~5,261 HEIST) and some pendingBurnETH from organic trading (output.txt:1541-1542).
• Attacker can flash-loan WETH (Morpho) and create new Uni v4 pools referencing the hook.
• HEIST is transferable so the attacker can seed / receive LP amounts.

Attack walkthrough#

All line refs are from the offline -vvvvv output.txt.

Diagrams#

Remediation#

1. One-shot poolKey. In _beforeInitialize, if poolInitialized revert (or require msg.sender / a governance-set expected pool id). Never overwrite after first set.
2. Bind fee processing to an immutable pool id computed at deploy (or passed once in a privileged setPoolKey gated by owner/timelock).
3. Slippage / minOut on fee conversion. Even with a fixed pool, sandwiching large inventory dumps is a real risk — require TWAP bounds or a keeper-only path.
4. Access-control processFees/processBurn (keeper role) if public conversion is not required for product reasons.

How to reproduce#

# Offline (no RPC) — canonical
_shared/run_poc.sh 2026-05-HeisenbergHook_exp -vvvvv

# Online warm (if rebuilding anvil_state)
python3 _shared/run-poc/exhaustive_warm.py 2026-05-HeisenbergHook_exp mainnet "$ETH_RPC" --block=25059345

Reference: ExVul security alert — Heisenberg HEIST HeisenbergHook Uniswap V4 hook

Links#

• Standalone PoC + full trace: 2026-05-HeisenbergHook_exp (this folder).
• Attack tx: 0x938216ea….
• Victim: HeisenbergHook 0xBea9…2ac8.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2026-05-HeisenbergHook_exp (evm-hack-registry mirror).
• Attack transaction: view on explorer.

Alerts & third-party analyses

• Original alert / thread: post on X.
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.