Spiral Uniswap V4 Price Manipulation Exploit Drained ETH From DeFi Lending Protocol

Spiral’s DeFi lending system suffered a reported exploit after its SpiralHookV2 borrow function valued collateral using an instantaneous Uniswap V4 pool price. The attacker manipulated the pool, borrowed against the inflated collateral and extracted approximately 10.7 ETH, estimated at about $26,800.

How the Spiral exploit worked

Incident reporting identified SpiralHookV2.borrow() as the key affected function. It used poolManager.getSlot0() to read the current Uniswap V4 pool price and value collateral. Because the price was instantaneous rather than time-weighted, an attacker could move the pool price and present an inflated collateral value to the lending logic.

The attacker then borrowed against that manipulated collateral in the same block. The reported loss was approximately 10.7 ETH, although the dollar estimate can change with ETH’s price and the final accounting of the affected contracts.

Incident element	Reported detail
Incident date	September 14, 2026
Affected system	SpiralHookV2 and related Spiral contracts
Pricing source	Instantaneous Uniswap V4 pool price from getSlot0()
Reported loss	Approximately 10.7 ETH, or about $26,800
Attack method	Pool-price manipulation followed by borrowing against inflated collateral
Timing	Manipulation and borrowing completed in the same block
Reported bypass	Six separate EOAs bypassed the noSameBlockSwap control

Why same-block protection failed

Spiral reportedly had a noSameBlockSwap protection intended to prevent a price move and borrow from occurring together. The attacker bypassed that control by using six separate externally owned accounts, allowing the manipulation and borrowing steps to avoid the protocol’s assumed relationship between one caller and one transaction path.

A caller-level restriction is not the same as an economic restriction. If an attacker can split actions across addresses or contracts, a protocol must enforce the relevant invariant at the pool, market and block level rather than assuming that a single address represents the entire strategy.

The incident also shows the danger of using a spot AMM price as a lending oracle. A large temporary trade can move the apparent price without changing the market’s durable value. If that price controls borrowing power, the attacker can turn temporary liquidity into undercollateralized debt.

Oracle and collateral-pricing lessons

Lending systems should prefer robust oracle designs that combine time-weighted prices, independent sources, liquidity thresholds and bounds on price movement. They should model low-liquidity pools, flash-loan-funded trades, concentrated liquidity and cross-account coordination before allowing a price to determine collateral value.

Protocols should also cap borrowing, impose debt ceilings, delay large collateral changes and pause markets when oracle prices move outside expected ranges. A same-block check can be useful, but it should complement rather than replace a manipulation-resistant price feed.

Users should treat lending markets that rely on a single AMM pool as higher risk, especially when collateral value can be changed by a large trade. Read the SlowMist incident entry and the readable incident report. Follow more DeFi security coverage at VORTFLUX.

Readers should verify current information, consider liquidity and legal terms, and evaluate market risks independently before taking action.