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.

5m read timeFrom coinsbench.com
Post cover image
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 Learned

Sort: