Oracle infrastructure vulnerabilities in disclosed reports

Findings against the price infrastructure itself — aggregation, node operation, feed lifecycle and the guarantees consumers rely on.

Reports indexed
16
Total paid
$0
Critical
0
Largest payout
$0

Reports in this group target oracle systems rather than their consumers: aggregation logic, the node operator set, update cadence and the handling of feeds that are deprecated, paused or newly listed.

The recurring theme is the gap between what an oracle guarantees and what integrators assume it guarantees. Heartbeat and deviation thresholds describe the worst case, not the typical case, and a consumer that treats the typical case as guaranteed is the one that gets exploited.

Read these alongside the oracle manipulation category, which covers the consumer side of the same relationship.

What reviewers look for

  • Aggregation that tolerates a small number of malicious reporters
  • Feed lifecycle events — deprecation, pause, migration — unhandled by consumers
  • Update cadence assumptions that do not hold under congestion
  • Fallback and circuit-breaker behaviour that fails open
  • Newly listed feeds with sparse reporter coverage

Curated highlights

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

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

Optimism: An attacker can bypass the challenge period during LPP finalization

The Optimism PreimageOracle protocol contains a logic vulnerability that allows attackers to bypass the mandatory challenge period for Large Preimage Proposals (LPP). By intentionally failing to finalize the proposal during data submission, an attacker leaves the proposal's timestamp uninitialized (zero), causing the finalization check to inadvertently pass. This allows malicious or invalid preimage data to be finalized instantly, undermining the integrity of the oracle and the dispute mechanism.

Optimismcode4renaAug 16, 2024Open
highOracle manipulationEVM-Solidity$0

Optimism: LPP metadata can be altered after the challenge period is over, allowing incorrect states to be proven

The Optimism PreimageOracle allows for the manipulation of Large Preimage Proposal (LPP) metadata, even after the challenge period has concluded. By exploiting a lack of re-initialization checks and redundant storage reads, an attacker can overwrite critical proposal data. This manipulation compromises the integrity of the MIPS VM state, as the system can be coerced into accepting fraudulent preimage data due to the absence of consistency checks in the `squeezeLPP` function.

Optimismcode4renaAug 16, 2024Open
highOracle manipulationEVM-Solidity$0

Optimism: L2 precompile calls can be impossible to reproduce on L1

Optimism's fault-proof system uses a PreimageOracle on L1 to re-execute specific L2 precompiles. Certain precompiles, such as bn256Pairing, have dynamic gas costs that allow them to consume nearly the full block gas limit in a single transaction. Due to the inherent gas overhead in the L1 verification function and the EIP-150 gas forwarding limit, these high-gas L2 transactions cannot be successfully re-executed on L1. This failure prevents the fault-proof system from validating these specific state transitions, potentially allowing invalid L2 state to remain uncorrected.

Optimismcode4renaAug 16, 2024Open
mediumOracle manipulationEVM-Solidity$0

Renzo: `calculateTVL` may run out of gas for modest number of operators and tokens breaking deposits, withdrawals, and trades

A Denial of Service vulnerability exists in Renzo's `RestakeManager` contract due to high gas consumption in `calculateTVLs`. The function iterates through nested loops for every operator delegator and supported token, querying strategy share balances and oracle price feeds on each iteration. As the number of operator delegators and tokens increases, the execution gas cost scales quadratically and can exceed the Ethereum block gas limit. Because `calculateTVLs` is called in core protocol operations—including deposits, withdrawals, and rate provider queries—gas limit exhaustion causes these primary protocol functions to revert and freeze operations.

Renzocode4renaJun 7, 2024Open
mediumOracle manipulationEVM-Solidity$0

Revert Lend: Large decimal of `referenceToken` causes overflow at oracle price calculation

The V3Oracle contract in Revert Lend incorrectly structures its arithmetic for normalizing Chainlink price feeds, leading to integer overflows when handling tokens with 18 decimals. By multiplying large powers of 10 with price data in Q96 format within a single operation, the code exceeds the capacity of uint256 for certain price ranges. This causes the oracle to revert, effectively disabling the Chainlink price feed and forcing the protocol to rely on fallback pricing mechanisms.

Revert Lendcode4renaMay 22, 2024Open

All reports in this group

Vulnerability classes seen in this protocol type

Related protocol type pages