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
115
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

Centrifuge Protocol V3.1: `SimplePriceManager.onUpdate()` lack of forward execution fee leads dependent functions to revert

Centrifuge's SimplePriceManager.onUpdate() routes share-price updates through Gateway.withBatch(), but the function is not payable and forwards no native token, so the outgoing batch runs with zero execution fuel. When the protocol is not in unpaidMode, Gateway._send() cannot satisfy fuel >= cost and reverts with NotEnoughGas. This permanently DoSes NAV and oracle price propagation for any caller using NAVManager.updateHoldingValuation() or OracleValuation.setPrice(). The fix makes onUpdate() payable and forwards msg.value to withBatch().

Centrifuge Protocol V3.1sherlockNov 17, 2025Open
mediumLogic errorEVM-Solidity$0

Super DCA Liquidity Network: Manager can retroactively apply new rate to past time, misallocating emissions - Invariant Broken

SuperDCAStaking distributes emissions to stakers through an accruing rewardIndex whose exact increment formula is contractually guaranteed by the protocol readme. The guard in setMintRate() re-assigns the emission rate without first settling rewards for the time elapsed since lastMinted. As a result the entire past interval is priced at the new rate rather than the rate that was in effect, so a rate change retroactively re-prices already-earned rewards. This lets a manager or any holder of the rate-setter role backdate a rate change, overpaying or underpaying stakers and breaking the documented invariant. The protocol acknowledged and fixed the issue in the referenced pull request.

Super DCA Liquidity NetworksherlockOct 3, 2025Open
mediumOracle manipulationOther$0

Brevis Pico ZKVM: Malicious verifier will recover private witness values breaking zero-knowledge property

Brevis Pico, a privacy-preserving zkVM, relies on a fork of the gnark proving library (v0.1.0) that carries CVE-2024-45040: the Groth16 proving system emits Pedersen commitments without blinding factors. Because the BabyBear, KoalaBear, and verifier circuits invoke RangeChecker.Check() (which internally uses these unblinded commitments) whenever the GROTH16 environment variable is not set to 1 — the production default — a verifier who holds a proof can brute-force low-entropy private witnesses by regenerating commitments over candidate values and matching them. The accompanying Go PoC demonstrates recovery of a 10-bit secret from a proof commitment. This directly violates the zero-knowledge privacy guarantee the zkVM advertises, exposing program traces, memory access patterns, and confidential inputs such as keys or merkle leaves. The protocol team acknowledged the finding and fixed it in pull request #61, with the recommended mitigation being an upgrade to gnark 0.11.0.

Brevis Pico ZKVMsherlockSep 29, 2025Open
highLogic errorEVM-Solidity$0

Mellow Flexible Vaults: RedeemQueue Accounting Mismatch Between Batch Creation and Claim Eligibility

The Mellow Flexible Vaults RedeemQueue has an inconsistent timestamp boundary between how batches are created and how claims are validated. When processing an oracle report, _handleReport decrements the latest eligible index (excluding the newest redemption request at or before the report timestamp) when building the batch, while the claim path allows redemption requests up to and including that same timestamp to be claimed from that batch. Consequently, a user whose redemption belongs to a later batch can withdraw assets from an earlier batch that never accounted for their shares, depleting the batch and causing other users' claims to fail or revert with division-by-zero. The affected shares then get baked into a subsequent batch the user can no longer claim from, producing permanent fund lockup. The protocol team fixed the issue in PR mellow-finance/flexible-vaults#11, and the report includes a reproduction test.

Mellow Flexible VaultssherlockJul 28, 2025Open
mediumLogic errorEVM-Solidity$0

Mellow Flexible Vaults: cancelDepositRequest() always reverts due to modifying FenwickTree with wrong index

Mellow Flexible Vaults' DepositQueue.cancelDepositRequest() mistakenly uses the latest oracle price checkpoint's index to remove a user's pending deposit from the Fenwick tree that is indexed by deposit timestamps. Because the price-trace array has a different length and indexing basis than the timestamp-based request trace, the derived index is out of bounds and modify() reverts with IndexOutOfBounds on every call. As a result, depositors cannot cancel queued deposits and their funds stay locked until the queue naturally processes them, breaking a core piece of expected behavior without stealing funds. The protocol resolved it by deriving the Fenwick index from the user's request timestamp via lowerLookup() instead of the price checkpoint.

Mellow Flexible VaultssherlockJul 28, 2025Open
highLogic errorEVM-Solidity$0

Mellow Flexible Vaults: Protocol Fee Multiple Accrual in Oracle.submitReports

Mellow Flexible Vaults' report-submission pipeline accrued protocol fees once per asset report instead of once per batch because the stored fee timestamp is refreshed only when the base asset is reported. When a single Oracle.submitReports transaction processes several non-base assets before the base asset, FeeManager.calculateFee repeatedly uses the same stale timestamp and mints protocol fees for the same elapsed period each time. The result is that a vault can overcharge protocol fees proportional to the number of non-base assets in a single batched submission. The finding was acknowledged and fixed by the protocol team, and the loss is economic: excessive fee shares minted to the fee recipient at the expense of vault shareholders.

Mellow Flexible VaultssherlockJul 28, 2025Open

All reports in this group

Vulnerability classes seen in this protocol type

Related protocol type pages