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
- 7
- 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.
Ammplify: Accrued maker fees not yet compounded can be stolen by manipulating uniswap pool spot price to reduce fees equivalent liquidity and liquidity share price on maker liquidity deposit
Ammplify, a Uniswap V3-based AMM, computes an "equivalent liquidity" figure from accrued-but-uncompounded maker fees by dividing fee value by per-unit-liquidity value at the live pool spot price (slot0). Because slot0 is manipulable within a single transaction, an attacker can drive the price to a point that collapses the equivalent-liquidity denominator, deposit maker liquidity at a deflated share price to receive extra shares, then restore the price and withdraw at the true share price — siphoning a large share of other makers' unbundled fees. The report's worked example shows ~387 token0 net profit against 977 token0 of fees with only ~2% manipulation cost, and the attack is repeatable and scalable.
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.
HydraDX: Malicious liquidity provider can put pool into highly manipulatable state
HydraDX's StableSwap AMM enforces a minimum-liquidity invariant so that pools cannot be reduced to easily manipulable dust: total pool issuance must stay at or above MinPoolLiquidity or be exactly zero. The remove_liquidity_one_asset() withdrawal enforces this with two checks, but withdraw_asset_amount() only validates the caller's own share balance and never inspects the pool's total issuance. Because LP shares are transferable, a malicious provider can deposit the minimum, move a single share to another address they control, then withdraw everything via withdraw_asset_amount(), leaving a pool with only dust liquidity. This breaks the stated invariant, making the degraded pool easier to price-manipulate and temporarily preventing other LPs (such as fixed smart contracts) from exiting through remove_liquidity_one_asset(). HydraDX confirmed the missing check but disputed severity, and the judge ruled Medium on the grounds of a rare edge-case temporary availability impact.
Tapioca: Secondary Big Bang market rates can be manipulated due to not triggering penrose.reAccrueBigBangMarkets(); when leveraging
Tapioca's Big Bang interest-rate accrual has an ordering gap: a guard added after its C4 and Spearbit audits only forces secondary-market accrual when the ETH market borrows directly through a dedicated Penrose function. Borrowing through the leverage modules instead runs an internal _borrow() in BBLeverage.buyCollateral() without invoking that guard, so an attacker can take a large ETH-market loan while deferring secondary-market accrual, then trigger accrual on the non-ETH markets, which compute their rates from the inflated ETH-market debt and record distorted values. That lets the attacker steer secondary-market rates to favorable levels and profit while other users are adversely affected. The fix is to call reAccrueBigBangMarkets() on the leverage path so secondary markets accrue before any leveraged borrow, which the Tapioca team merged in PR #365.