CoinBuggie

Oracle manipulation vulnerabilities in disclosed bug bounty reports

When a protocol trusts a price it cannot defend, an attacker moves the price instead of attacking the protocol.

Reports indexed
152
Total paid
$900k
Critical
1
Largest payout
$900k

Oracle manipulation is rarely a bug in the oracle. It is a bug in what the consuming protocol is willing to believe. A lending market that reads a spot price from a thin pool, a vault that values its own LP token by calling the pool it is inside of, a liquidation engine that never checks how old a Chainlink round is — all of these are sound contracts fed bad numbers.

The payouts in this class cluster around two mistakes. The first is using an instantaneous value where a time-weighted or multi-source value belongs. The second is failing every safety rail the oracle already provides: unchecked staleness, ignored round completeness, no deviation bound, and no fallback when the primary feed reverts.

Because oracle bugs are about integration rather than implementation, they surface disproportionately in reports against lending protocols and structured-product vaults built on top of otherwise well-audited primitives.

What reviewers look for

  • Spot reserves or `getAmountsOut` used as a price source
  • Missing staleness, round-completeness or deviation checks on a push feed
  • LP token valuation derived from the pool's own current reserves
  • A single feed with no fallback and no circuit breaker
  • Prices sourced from a pool shallow enough to move within one transaction

Curated highlights

The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.

criticalOracle manipulationEVM-Solidity$900k

Spot TWAP oracle manipulated via single-block flash loan

A perpetual derivatives protocol relied on a Uniswap V3 TWAP oracle whose pool observation cardinality was capped at 12, severely reducing its intended 30-second time-weighted average window. An attacker executed a single-block flash loan to heavily distort the underlying spot price without triggering any secondary price feed validation. This allowed the attacker to open oversized leveraged positions at an artificial mark price and force liquidations against counterparties in a single atomic transaction.

Perp DEXsherlockAug 2, 2023Open
highOracle manipulationEVM-Solidity$0

Good Entry: Incorrect Solidity version in FullMath.sol can cause permanent freezing of assets for arithmetic underflow-induced revert

Good Entry ported Uniswap v3's FullMath.sol into its TokenisableRange code but under a Solidity ^0.8.4 pragma instead of the original pre-0.8 unchecked-arithmetic pragma, which silently turns its intermediate subtractions into checked, reverting operations. As a result, LiquidityAmounts.getAmountsForLiquidity reverts on underflow whenever the pool's market sqrt price ratio falls below a range position's lower tick, a condition the author demonstrates with real mainnet prices and argues can be permanent when one asset keeps appreciating. Since that helper feeds returnExpectedBalance and the deposit/withdrawal paths of range positions, affected users can be locked out of their funds. The sponsor confirmed the faulty library version and replaced it with the correct Uniswap v3 0.8-branch libraries, with the mitigation verified in a follow-up audit.

Good Entrycode4renaAug 7, 2026Open
highOracle manipulationEVM-Solidity$0

Good Entry: Overflow can still happen when calculating `priceX8` inside `poolMatchesOracle` operation

Good Entry's GeVault compares a Uniswap v3 pool price against a Chainlink oracle inside poolMatchesOracle to decide whether a rebalance should occur. The computed priceX8 value derives from the pool's sqrtPriceX96, and the code pre-scales it by only 2**12 before squaring, which is insufficient to prevent the intermediate multiplication from overflowing the uint accumulator. Using live WBTC/WETH pool data, the researcher reproduces an arithmetic over/underflow revert that breaks the price comparison and therefore the rebalance path. The sponsor confirmed the finding and shipped a fix that rescales the price using the Uniswap v3 OracleLibrary convention, with the mitigation later confirmed in a follow-up audit.

Good Entrycode4renaAug 7, 2026Open
highOracle manipulationEVM-Solidity$0

Good Entry: TokenisableRange's incorrect accounting of non-reinvested fees in "deposit" exposes the fees to a flash-loan attack

Good Entry's TokenisableRange wraps Uniswap V3 positions and attempts to claw back accumulated trading fees on every deposit/withdraw by capping reinvestment at ~1% of pool value and discounting newly minted LP tokens by the fee share they confer. Both safeguards can be defeated: the reinvestment check compares raw fee token amounts rather than their price-weighted value, so after a large price move the fees can far exceed the 1% cap without triggering reinvestment, and the LP-token discount is skipped outright whenever a few wei of the secondary token are supplied alongside a deposit. An attacker can therefore flash-loan a large single-sided amount, add a token-amount dust supply to disable the discount, deposit to capture the majority of pool shares, and immediately withdraw to seize the bulk of the accumulated fee0/fee1 balances. The confirmed, mitigated finding includes a working mainnet-fork PoC showing a risk-free ~1.58 WETH profit that is multiple times the intended 1% cap.

Good Entrycode4renaAug 7, 2026Open
mediumOracle manipulationEVM-Solidity$0

Metric: Discarding sub-quantum oracle precision lets low-priced assets trade below their signed value

Metric's oracle consumer floors Pyth Lazer prices to eight decimals when a feed's exponent is below -8, truncating the sub-quantum remainder without folding the discarded quantization error into the spread or uncertainty band used by the anchored price provider. Because the provider constructs its protective bid/ask band around that already downward-biased midpoint, a fresh, correct and stale-free Pyth report for a low-priced asset like SHIB can still let a permissionless swapper buy the token out of the pool below its correctly signed oracle value. In the demonstrated configuration an LP funding 25,000,000,000 SHIB (worth about $102,942.50 at the correct midpoint) loses roughly $89.70 of mark-to-market principal, which clears Sherlock's Medium thresholds of both 0.01% of affected principal and $10. The protocol team acknowledged and fixed the issue in a follow-up commit.

MetricsherlockJul 27, 2026Open
mediumOracle manipulationEVM-Solidity$0

stNXM by EaseDeFi: Missing Uniswap V3 cardinality initialization in `StNxmOracle` leads to permanent Denial of Service

The StNxmOracle contract prices stNXM from a 30-minute Uniswap V3 TWAP, but its constructor only stores the pool address and never grows the pool's observation buffer. Newly initialized Uniswap V3 pools keep a default observationCardinality of 1, which holds only the current block, so OracleLibrary.consult requests for 1800 seconds of history always revert. Every price() call therefore fails and the oracle is unusable, bricking the Morpho lending markets that depend on it for collateral valuations until an external actor manually raises the cardinality. The root cause is an initialization gap in the constructor: it must call increaseObservationCardinalityNext (e.g., 100 slots) before the oracle is used. This was a Sherlock medium finding fixed by the protocol team in commit 98c0058.

stNXM by EaseDeFisherlockNov 21, 2025Open

All reports in this group

Chains where this class shows up

EVM · Solidity Solana · Rust Move Other chains and infrastructure

Related vulnerability category pages

Reentrancy Flash loan attack Access control Integer overflow / underflow Signature replay Front-running / MEV Bridge exploit Price manipulation Logic error Governance attack