CoinBuggie

Cosmos SDK and IBC vulnerabilities in disclosed bug bounty reports

App-chain security is consensus security: a module bug can halt a chain or mint supply without any contract being involved.

Reports indexed
133
Total paid
$250k
Critical
0
Largest payout
$250k

Cosmos chains ship their own state machine, so the vulnerable surface is module code rather than deployed contracts. Non-deterministic execution across validators, unbounded iteration in `BeginBlock`, and panics reachable from user messages all translate directly into liveness failures for the whole network.

IBC adds a cross-chain layer with its own failure modes: packet timeout handling, acknowledgement processing, and the escrow accounting that keeps voucher supply matched to locked supply. Several of the highest-value disclosures in this environment are IBC accounting bugs rather than exploits in the usual sense.

Where CosmWasm is in play, the contract-level classes from the EVM taxonomy reappear, with the addition of reply-handler and submessage ordering issues specific to the runtime.

What reviewers look for

  • Non-deterministic behaviour across validator implementations
  • Unbounded loops or unbounded state growth in block handlers
  • Panics reachable from unauthenticated messages
  • IBC escrow accounting divergence between chains
  • CosmWasm reply handlers processing untrusted submessage results

Curated highlights

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

highAccess controlCosmos-SDK$250k

Cosmos SDK module allows unauthorized state migration via missing ante handler check

A logic flaw in a Cosmos SDK module's state migration handler allowed unauthorized signers to execute privileged state updates. The message authority check relied on a helper function that returned true when the authority field was empty, and the message route was incorrectly exposed as a standard transaction rather than being restricted to governance. An attacker could issue state updates with an empty authority field to inject malicious counterparties into the IBC channel allowlist, enabling the execution and processing of forged cross-chain transactions.

IBC App ChainimmunefiDec 5, 2023Open
mediumInteger overflow/underflowCosmos-SDK$0

Dango DEX: Inconsistent multiplication during order creation and cancellation can lead to panics and Denial of Service during order cancellation

Dango DEX, a Rust-based order-book DEX built on the LeftCurve/Grug framework, uses inconsistent multiplication paths when computing ASK quote amounts at order creation versus cancellation. Creation employs an integer-times-decimal multiplication that narrows after dividing by precision, while cancellation multiplies two decimal values whose raw product can exceed u128. An attacker can place an ASK order at a maximum price such that creation succeeds but cancellation always overflows and panics, permanently blocking the administrator's ForceCancelOrders cleanup and creating a persistent administration-level denial-of-service, with no direct loss of funds.

Dango DEXsherlockSep 29, 2025Open
mediumLogic errorCosmos-SDK$0

Dango DEX: Ineffective minimum order size check for ASK limit orders can lead to Denial of Service

Dango DEX's ASK-limit-order creation validates order size against the user-supplied quote value, computing amount_in_quote as base times the order's limit price. An attacker can defeat this by posting a 1-wei base quantity with an arbitrarily high price, generating a large volume of economically trivial ImmediateOrCancel orders that never fill. When the cron-driven auction sweeps and refunds all pending IOC orders in a single pass, the excessive order count can blow past block execution time and stall block production on the Tendermint/CometBFT chain. The same flood also exhausts gas in the owner-only ForceCancelOrders path, which cancels every order type, effectively blocking emergency order-book management.

Dango DEXsherlockSep 29, 2025Open
mediumLogic errorCosmos-SDK$0

Dango DEX: A newly deployed pool can be DoS

A freshly deployed Dango DEX pool can be permanently bricked (DoS) by any caller supplying exactly zero of both base and quote assets as the very first liquidity provision. Because the code never validates that the initial deposit amounts or the first LP token mint are non-zero, the pool ends up in a state where reserves are still zero but LP supply is non-zero. Every subsequent liquidity provision then invokes add_subsequent_liquidity, which divides by the zero invariant/reserve value and reverts with an arithmetic error, leaving the pool unable to ever operate.

Dango DEXsherlockSep 29, 2025Open
mediumInteger overflow/underflowCosmos-SDK$0

Dango DEX: User can pause all auctions by overflow in mid-price average

Dango DEX's on-chain cron job clears and re-saves resting orders for each trading pair each block, computing a mid-price from the best bid and best ask. Because these prices are stored as Udec128_24 fixed-point values, computing mid_price = (bid + ask) / 2 can overflow at the addition step when the ask is near the type maximum and the bid is a positive value. A user can intentionally place one extreme GTC sell and one small GTC buy on a fresh pair with no passive reserves, so no match occurs and the unchecked checked_add overflows when the resting book is saved. The resulting error bubbles out of the auction submessage into a reply handler that unconditionally sets a global PAUSED=true flag, causing a denial of service on auctions across every pair. The fix is to compute the mid price with the subtraction-safe form lo + (hi - lo) / 2 so the two extremes are never added.

Dango DEXsherlockSep 29, 2025Open
mediumLogic errorCosmos-SDK$0

Dango DEX: XYK reflect_curve omits swap fee in order sizing, leaking LP fees

Dango DEX's XYK passive-liquidity reflect_curve computes total order sizes from pool reserves without applying the configured swap fee, so reflected passive orders are matchable as if they were fee-free. A taker can match these orders and pay no swap fee while the pool fails to accrue the fee that liquidity providers should earn. The finding includes a Rust test showing that after matching a passive bid at price 0.99 under a 1% fee, the constant-product invariant K does not increase, confirming no fee accrued. The proposed fix incorporates the (1 - f) term into both the bid and ask sizing formulas.

Dango DEXsherlockSep 29, 2025Open

All reports in this group

Vulnerability classes seen on this chain

Access control Integer overflow / underflow Front-running / MEV Logic error

Related chain / vm pages

EVM · Solidity Solana · Rust Move Other chains and infrastructure