coinbuggie

DEX vulnerabilities in disclosed bug bounty reports

Automated market makers hold liquidity and publish a price, which makes them both a target and the instrument used against other protocols.

Reports indexed
98
Total paid
$1.2M
Critical
1
Largest payout
$900k

A DEX is an invariant plus a pool of assets, and almost every finding is a way to push the invariant somewhere it was not meant to go: rounding that favours the swapper, fee accrual that can be zeroed, callback hooks in concentrated-liquidity designs that re-enter mid-swap, and router paths that trust a user-supplied token list.

Just as often the DEX is not the victim. Its spot price is read by a lending market, its LP token is valued by a vault, and a pool with thin liquidity becomes the cheapest lever available against a much larger protocol.

Reports here pair naturally with the price manipulation and oracle manipulation categories.

What reviewers look for

  • Invariant checks skipped or performed before external interaction
  • Router paths accepting arbitrary intermediate tokens
  • Swap callbacks re-entering pool state
  • Rounding direction favouring the caller
  • Pool depth low enough to move within a single 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
highInteger overflow/underflowMove$180k

Unchecked arithmetic in Move coin split enables balance underflow

A custom coin-splitting helper in a Move-based decentralized exchange implemented unsafe u128 downcasting that bypassed native Move checked arithmetic. Combined with a stale balance check preceding an internal callback, an attacker could request a swap amount exceeding their actual balance. The resulting u128 subtraction underflow truncated upon downcasting into a valid u64 value, crediting the attacker with an artificially inflated balance that could subsequently be drained from the exchange.

Move DEXhatsSep 27, 2023Open
mediumFlash loan attackEVM-Solidity$75k

Flash-loanable veToken balance inflates emissions gauge weights

A design flaw in the gauge voting system allowed real-time veToken balance checks instead of utilizing checkpointed block or epoch snapshots. An attacker could execute a flash loan to acquire governance tokens, temporarily lock them to generate veToken voting power, vote to direct reward emissions toward their target gauge, and release the lock to repay the flash loan within the same block. This enabled uncollateralized, risk-free manipulation of protocol reward distributions.

Gauge Emissionscode4renaFeb 2, 2024Open
lowLogic errorEVM-Solidity$9k

Oracle-free AMM invariant rounding allows slow drain

A directional rounding flaw in the Newton-Raphson solver for a StableSwap invariant enabled subtle value extraction during token exchanges. When computing invariant values and target balances, both routines rounded down, yielding an extra wei of token output to the user on specific balance ratios. On low-fee Layer 2 blockchains, an automated script could execute high-frequency minimal swaps to steadily extract pool reserves over time.

Stableswap PoolhatsApr 9, 2024Open
mediumLogic errorEVM-Solidity$0

Good Entry: V3 Proxy does not send funds to the recipient, instead it sends to the msg.sender

Good Entry's V3 proxy wrapper exposes swap functions intended to be compatible with the Uniswap V2 interface, but these functions ignore the caller-supplied destination address and instead route output tokens to msg.sender. Any caller who passes a different `to` address loses the economic value of the swap — for instance a user blacklisted on the output token, or one whose allowance/signature was compromised and who tries to divert proceeds to a safe address, ends up with funds sent back to the caller. The issue was confirmed by the protocol and the judge rated it Medium; the final fix added an explicit `require(msg.sender == to)` to enforce that swaps only ever go to the caller, which is safe for the OPM-only usage the module was designed for.

Good Entrycode4renaAug 7, 2026Open
mediumLogic errorEVM-Solidity$0

Rubicon: Incorrect fee handling in `Position.sol's` Market `Buy`/`Sell` functions

Rubicon's `Position.sol` helpers `_marketBuy` and `_marketSell` pre-calculate the market fee and inject it into their order sizing before routing through `RubiconMarket`, which already accounts for the same fee on v2 trades. The result is double (incorrect) fee accounting that yields improper fee deductions and wrong trade execution whenever a user opens or closes a leveraged position via the swap path. The sponsor confirmed fees should not be handled in these helpers, and the judge reduced the severity to Medium after noting that the wider `RubiconMarket` fee logic contains many errors. The finding was reported by many participants and consolidated as a duplicate group led by issue #282.

Rubiconcode4renaFeb 17, 2025Open

All reports in this group

Vulnerability classes seen in this protocol type

Reentrancy Oracle manipulation Flash loan attack Access control Integer overflow / underflow Front-running / MEV Price manipulation Logic error Governance attack

Related protocol type pages

Lending Bridge Oracle NFT Stablecoin Other protocols