A security researcher discovered a critical vulnerability in a custom Uniswap v4 StableSwap Hook during a private bug bounty program. The flaw stemmed from using a single global reserves array shared across all pool pairs instead of isolating state per PoolId. By dumping large amounts of a low-liquidity token (DAI) into a secondary pool (USDC/DAI), an attacker could skew the global StableSwap invariant D, causing manipulated pricing in an unrelated high-value pool (USDC/USDT). A Foundry proof-of-concept confirmed the exploit allowed draining USDT from liquidity providers at artificially cheap rates. The fix required remapping reserves strictly to their respective PoolIds. Key lessons: always enforce PoolId state isolation in Uniswap v4 Hooks, and auditors should verify that mathematical inputs are scoped to the correct pool context.
Table of contents
The Target: A StableSwap Hook on Uniswap V4The Vulnerability: The “Shared State” SinThe “Aha!” MomentGet Hacker MD’s stories in your inboxThe Exploit Path (Step-by-Step)The ImpactLessons LearnedSort: