ArrakisGUNI exploit analysis

The Arrakis Finance V1 (G-UNI) ENS/WETH vault at 0x7c687f775A3b73BBAb0E15832F24caaB5D53bDDe (proxy, implementation ArrakisVaultV1 at 0xd68b055fB444D136e3ac4Df023f4c42334F06395) valued its Uniswap V3 position for the permissionless mint() and burn() path off the pool's instantaneous slot0() spot price, via getUnderlyingBalances and LiquidityAmounts on the live sqrtPriceX96. The contract's TWAP and deviation guard wrapped only the manager rebalance() path. The mint() and burn() paths had no TWAP and no deviation check. An unprivileged caller could push the V3 tick with a swap, mint shares at the skewed valuation, restore the tick, and burn the shares for a richer token mix than deposited.

The attacker (EOA 0xa3B096e4df1247794599a37Af8F5b8CB05D5EB44, via original attack contract 0x028d9C17B1a097e7e115A6400203df86339BAf4A) ran the exploit in a single transaction on block 25817966 of Ethereum (0x6ae3af4b2f25a56594de99cfb31369150dd9ac059c49efe04b9e3e0163dbc672), flash-loaning 1,800 WETH from Morpho Blue as working capital. Inside the Morpho callback the attacker swapped 150 WETH into ENS on the pool down to the min-price bound, with ~145.42 WETH in and ~13,292.5 ENS out, skewing the tick. With slot0 driven to its floor, manualWithdraw -- actually vault.mint(4486619135659964587643, this) -- deposited ~1,253.39 WETH plus ~13,159.59 ENS for the shares, priced at the skewed spot.

The attacker then swapped ~132.93 ENS back into WETH for a partial tick restore, called vault.burn on the same shares, and redeemed ~1,248.41 WETH plus ~13,283.30 ENS, a WETH-poorer but ENS-richer mix than deposited. The attacker swapped the entire ENS balance back to WETH and repaid the 1,800 WETH flash loan. The ~2.9414 WETH left over is the profit. The on-chain original contract forwarded the surplus to the EOA after a 0.05 ETH tip to a builder address; that tip is downstream monetisation rather than the vulnerability, so this PoC measures the raw WETH surplus.

The fix is to source the underlying valuation for mint() and burn() from the same TWAP the manager rebalance uses, with the same deviation guard, rather than from the live slot0. Even a one-block TWAP over the prior few blocks would have prevented the flash-loan-funded push-and-restore from setting the price the same block the attacker then read.