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
92
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
mediumOracle manipulationEVM-Solidity$0

BendDAO: Major insolvency risk in `LiquidationLogic::executeCrossLiquidateERC721()` due to not setting a maximum liquidation price

The BendDAO lending protocol suffers from an insolvency risk during market downturns due to a flawed liquidation pricing mechanism in its cross-liquidation logic. Because the protocol calculates the required repayment by dividing total debt by the number of collateral tokens without applying a maximum price cap, the cost for liquidators to repay the debt can exceed the market value of the underlying NFTs. This makes liquidations unprofitable during periods of high volatility or asset price drops, effectively blocking the system from shedding bad debt and shifting the burden of loss to the DAO treasury.

BendDAOcode4renaSep 3, 2024Open
mediumOracle manipulationEVM-Solidity$0

BendDAO: No check if Arbitrum/Optimism L2 sequencer is down in Chainlink feeds `PriceOracle.sol`

The BendDAO protocol fails to verify the operational status of the L2 sequencer when fetching price data from Chainlink feeds. In the event of sequencer downtime, oracle data becomes stale, yet the protocol continues to use these outdated prices for core lending operations. This deficiency creates a significant risk where users could borrow against or evade liquidation for collateral that has substantially lost value, as the protocol's accounting remains unaware of the real-time price drops.

BendDAOcode4renaSep 3, 2024Open
mediumOracle manipulationEVM-Solidity$0

BendDAO: Updating asset collateral params can lead to liquidate borrowers arbitrarily

The protocol's health factor calculation is susceptible to immediate, retroactive changes via administrative parameter updates. By updating the liquidationThreshold and collateralFactor for a given asset to zero, an administrator can instantaneously render existing, healthy borrow positions liquidatable. This occurs because the smart contract checks the current configuration values at the time of health factor calculation rather than using parameters fixed at the time the loan was initiated, enabling liquidators to profit from unsuspecting borrowers.

BendDAOcode4renaSep 3, 2024Open
mediumOracle manipulationEVM-Solidity$0

BendDAO: PriceOracle has invalid checks on price staleness

The BendDAO PriceOracle fails to adequately validate the freshness of Chainlink oracle price data, relying on an insufficient non-zero timestamp check and a deprecated round-tracking variable. This allows the protocol to accept stale price updates that may deviate significantly from current market prices. If a price feed stops updating, the protocol will continue to operate on obsolete data, potentially leading to incorrect collateral valuation or allowing for the manipulation of liquidations to an attacker's advantage.

BendDAOcode4renaSep 3, 2024Open
mediumOracle manipulationEVM-Solidity$0

BendDAO: `isolateRedeem()` revert in case Revert-on-zero-value-transfers tokens

BendDAO's `isolateRedeem` functionality can be bricked if the protocol's bid fine parameters are set to zero and the loan asset used is a token that reverts on zero-value transfers. When these conditions are met, any attempt by a borrower to redeem their loan from an active auction will trigger a transaction revert, as the contract attempts to transfer a zero-value fine to the auction bidder. This effectively prevents users from recovering their collateral until the auction concludes or the protocol configuration is updated.

BendDAOcode4renaSep 3, 2024Open

All reports in this group

Chains where this class shows up

Related vulnerability category pages