CoinBuggie

Front-running and MEV vulnerabilities in disclosed reports

Public mempools make transaction ordering an attacker-controlled parameter, and any protocol that assumes otherwise is exploitable for free.

Reports indexed
87
Total paid
$45k
Critical
0
Largest payout
$45k

Every pending transaction is a public announcement of intent. Front-running findings are the cases where acting on that announcement is profitable: sandwiching a swap with no slippage bound, claiming a first-mover reward someone else paid to discover, or racing a governance execution.

The class also covers the inverse — back-running and censorship — and the protocol designs that make ordering matter more than it should. Auctions settled in a single transaction, liquidations open to anyone with no commitment phase, and reveal steps that can be observed before they are committed all show up repeatedly.

Remediations in these reports are more varied than in other classes: commit-reveal, private submission, slippage and deadline parameters that are actually enforced, and batch settlement at a uniform clearing price.

What reviewers look for

  • Swap or redemption paths with default or unenforced slippage limits
  • Reward claims where discovery and settlement happen in separate transactions
  • Reveal steps whose value is derivable from the earlier commit
  • Auctions or liquidations settled purely on arrival order
  • Deadline parameters accepted but never compared to `block.timestamp`

Curated highlights

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

mediumFront-running / MEVEVM-Solidity$45k

Sandwichable liquidation bonus enables MEV extraction from borrowers

A lending protocol's liquidation routine executed collateral swaps through an AMM router with zero slippage protection (`amountOutMin` set to zero) while relying on spot prices for bonus calculations. Mempool searchers could sandwich pending liquidation transactions by driving up local pool prices beforehand, forcing the swap to settle at severely degraded exchange rates. This allowed MEV bots to siphon excess value from the liquidated borrower's remaining collateral pool.

Money Marketcode4renaMar 8, 2024Open
mediumFront-running / MEVEVM-Solidity$0

Good Entry: First depositor can break minting of liquidity shares in GeVault

GeVault's deposit function issues liquidity shares proportional to the vault's live token balances as reported by getTVL(), which reads the contract's aToken balances. Because the very first mint sets the initial share price at a fixed 1e10 wei baseline, a malicious first depositor can mint a negligible share, withdraw down to one wei of shares, and directly donate a large amount of the underlying to the vault, inflating the per-share value dramatically. A subsequent legitimate depositor then receives a near-zero share count for a large deposit, so most of their funds are effectively stolen, and the require(liquidity > 0) check bricks small deposits. The judge confirmed this as Medium severity since it requires front-running a brand-new zero-supply vault and only affects vault deployment.

Good Entrycode4renaAug 7, 2026Open
highFront-running / MEVEVM-Solidity$0

PoolTogether: Increasing reserves breaks PrizePool accounting

An accounting flaw in PoolTogether's `PrizePool` contract allows external reserve contributions to be misattributed and extracted by prize vaults. When `increaseReserve` is invoked, prize tokens are transferred into the contract and added to `_reserve`, but the helper `_accountedBalance()` is not updated. As a result, subsequent calls to `contributePrizeTokens` evaluate the unallocated token delta as total contract balance minus accounted balance, treating the newly deposited reserve funds as excess contributions. Any vault can claim these tokens, inflating its distribution accumulators and causing contract token balances to fall below accounted protocol liabilities.

PoolTogethercode4renaAug 7, 2026Open
highFront-running / MEVEVM-Solidity$0

Putty: `acceptCounterOffer()` May Result In Both Orders Being Filled

The Putty protocol suffered from a race condition in the acceptCounterOffer() function that allowed users to be unintentionally over-leveraged. An attacker could front-run the cancellation of an original order by filling it, which allowed the protocol to subsequently fill both the original and the new orders. This occurred because the cancellation function lacked a check to verify that the order was not already filled, leading to potential financial loss and excessive market exposure for users.

Puttycode4renaAug 7, 2026Open
mediumFront-running / MEVEVM-Solidity$0

PoolTogether: `Vault.mintWithPermit()` can be DoS'd

The `Vault.mintWithPermit` function allowed users to deposit into the vault using an ERC-2612 permit signature; however, it required the exact asset amount calculated from the current exchange rate. Because the exchange rate could fluctuate between signature generation and transaction execution, the hardcoded amount often caused the permit validation to fail. Attackers could front-run these transactions to manipulate the exchange rate, effectively creating a Denial-of-Service condition that prevented users from successfully minting shares. The protocol team eventually mitigated this issue by removing the problematic function entirely.

PoolTogethercode4renaAug 7, 2026Open
mediumFront-running / MEVEVM-Solidity$0

PoolTogether: `Claimer.claimPrizes` can be front-runned in order to make losses for the claim bot

The PoolTogether V5 prize-claiming mechanism was vulnerable to front-running, where malicious actors could cause large batch-claim transactions from automated bots to revert entirely. By claiming a single prize ahead of a bot's batched transaction, attackers exploited the contract's strict requirement that every prize in a batch must be eligible for claiming. This resulted in significant gas losses for the bots, undermining the economic incentive structure of the protocol's VRGDA-based claimer system. The flaw allowed attackers to disrupt honest market participants and potentially manipulate the dynamically adjusting prize fees for personal gain.

PoolTogethercode4renaAug 7, 2026Open

All reports in this group

Chains where this class shows up

EVM · Solidity Solana · Rust Cosmos SDK Other chains and infrastructure

Related vulnerability category pages

Reentrancy Oracle manipulation Flash loan attack Access control Integer overflow / underflow Signature replay Bridge exploit Price manipulation Logic error Governance attack