Price manipulation vulnerabilities in disclosed bug bounty reports
Distinct from oracle manipulation: here the protocol's own internal accounting of value is what moves.
- Reports indexed
- 3
- Total paid
- $300k
- Critical
- 0
- Largest payout
- $300k
Price manipulation findings target the pricing maths inside the protocol rather than the feed coming into it. AMM invariants that can be pushed outside their intended range, share-price accounting that responds to a direct token transfer, and rebalancing logic that can be triggered at a moment of the attacker's choosing.
Donation attacks are the canonical example — sending tokens directly to a vault so that `balanceOf` diverges from the internally tracked supply — and they keep working because internal accounting and actual balances are two different numbers that many contracts conflate.
This class overlaps with flash loans and oracles, and the reports here are cross-linked accordingly; the distinguishing question is whether the attacker moved an external number or a number the protocol computes itself.
What reviewers look for
- `balanceOf(address(this))` used where internal accounting belongs
- Curve or invariant maths valid only inside an unenforced range
- Rebalance or compound steps callable by anyone at any time
- Fee accrual that can be forced to round to zero
- Direct transfers into a contract changing its per-share value
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Stablecoin redemption path uses stale Chainlink round data
An algorithmic stablecoin's redemption module fetched Chainlink price data via latestRoundData without checking the update timestamp or round completeness status. During market volatility and L2 sequencer outages, oracle updates lagged, leaving stale collateral valuation in place on-chain. Attackers leveraged this discrepancy by buying discounted stablecoins on secondary markets and immediately redeeming them for full-value backing assets through the protocol.
Superposition: Lp's liquidity may be lost if re-org happens
In Superposition's Seawater AMM, users must remove liquidity in a separate transaction before burning their position NFT. If a block re-organization occurs, a third party can manipulate pool prices causing the liquidity removal transaction to revert due to slippage checks, while the subsequent position burn transaction succeeds. Because `burn_position` does not verify whether liquidity remains in the position, the position NFT is destroyed while the liquidity remains permanently locked in the contract.
Salty.IO: Salt Rewards - Rewards related to Arbitrage profits for pools can be lost
The Salty.IO protocol manages arbitrage profit distribution via a multi-step upkeep process where individual steps are isolated by try-catch blocks. An issue exists where a failure in the WETH-to-SALT conversion step causes the subsequent reward distribution step to proceed and clear the profit accounting records without having distributed the rewards. This creates a state where pool-specific profit data is discarded from the protocol's storage, resulting in a permanent loss of rewards for the liquidity providers who generated the arbitrage profits. Subsequent successful upkeep cycles then redistribute the rewards to current users based on an updated calculation, effectively disenfranchising the original liquidity providers.