Cosmos EVM exploit: what exchange users should check before deposits resume

TLDR

On Thursday, August 28, 2026, Cosmos Labs published a critical advisory and post-mortem for a Cosmos EVM balance-underflow exploit that affected six chains. The advisory says affected versions were below v0.6.2 and from v0.7.0 up to but not including v0.7.2, with no configuration-only workaround. The exchange-user takeaway is simple: if a chain, bridge or token route touched this incident, do not treat a reopened deposit page as enough proof. Verify the exact chain notice, the exchange notice, the token contract route and whether your venue has fully re-enabled normal processing.

Key takeaways

• Cosmos Labs says the exploit was active between August 20 and August 25, 2026 and affected six Cosmos-based networks.
• The GitHub advisory says the fix is in v0.6.2 and v0.7.2 or later, and says operators should halt rather than rely on configuration workarounds.
• Cosmos Labs says roughly $2.87 million in affected assets were sold on DEXes and an estimated additional $2.85 million was sold through centralized exchange accounts that were later frozen pending investigation.
• MANTRA's August 28 post-mortem says 720,923,967.99 MANTRA were moved from two addresses and that no validator keys, admin keys or multisig signers were compromised.
• KiiChain's emergency release notes say about 148.3 million KII were withdrawn, with 3,000,000 KII sent to a KuCoin deposit address on BNB Chain.
• CryptoGuide Exchange is an independent research and comparison platform, not an exchange, custodian, broker, investment adviser or legal adviser.

What happened

The official GitHub advisory describes a balance-underflow flaw in Cosmos EVM's StateDB handling. In plain English, the EVM layer tracked spendable balance differently from the Cosmos SDK balance model for vesting accounts. Under the wrong conditions, that mismatch could wrap a balance to an enormous number instead of failing safely. Cosmos Labs says there was no configuration-only mitigation and that chains needed to upgrade to patched releases or halt.

The incident matters for exchange users because chain exploits do not stay neatly inside chain code. The August 28 post-mortem says attackers moved funds through bridges, sold affected assets on DEXes, and also used centralized exchange accounts. That changes the practical user question from "Was my exchange hacked?" to "Has every route between the affected chain and my exchange actually been normalized?"

How the attack flow reached exchange users

1. Shared infrastructure flaw

The vulnerable code sat in a shared Cosmos EVM component, not in one exchange and not only in one chain app. That widened the blast radius.

2. Chain-level exploitation and halts

Cosmos Labs says MANTRA, TAC and KiiChain were among the first chains exploited and halted. MANTRA says its chain was down for roughly 30 hours. KiiChain says block production was halted the same day once the exploit was confirmed.

3. Bridge and liquidation routes

Cosmos Labs says attackers bridged assets to other networks and sold them for stablecoins and WETH. KiiChain's own release notes add a concrete exchange link: 3,000,000 KII were sent to a KuCoin deposit address on BNB Chain.

4. Reopening ambiguity

After a chain patch, users still face an operational gap. Deposits can remain paused at exchanges, wallet providers can lag the chain restart, and bridges may restore later than the base network. aelf's August 26 security update on a separate incident describes this well: public endpoints can be reachable before deposits, withdrawals or cross-chain operations are formally reopened. The same trust rule applies here.

User checklist before sending funds

1. Check the exact chain name and token route. "Cosmos" is not precise enough when multiple EVM-enabled chains and wrapped versions exist.
2. Check whether your exchange has reopened both deposits and withdrawals for that exact asset on that exact network.
3. Check whether the chain team published a final reopening notice, not only an exploit summary or a node patch.
4. Check whether your route uses a bridge, and whether that bridge published its own status update.
5. Check deposit-address history carefully. If an exchange changed memo, contract or routing details after the incident, old saved addresses can become a real risk.
6. Check whether your transfer is urgent enough to justify incident-period risk. Waiting one more day is often cheaper than debugging a stuck deposit across a recovering chain.
7. Check whether the token you are moving is native, wrapped or bridged. Recovery handling can differ sharply.

Comparison: what signals matter most

Risk notes

A chain restart is not the same as exchange normalization

Users often see a block explorer moving again and assume deposits are safe. That shortcut fails during incidents. Exchanges can keep transfers paused while they reconcile balances, swap deposit routes, or wait for additional confirmations from chain teams.

Bridged assets add a second layer of uncertainty

Cosmos Labs says stolen assets moved across bridges before being sold. If your normal route depends on a bridge, you need to confirm that bridge status separately from the chain restart.

Frozen exchange accounts do not equal full user recovery

The August 28 Cosmos Labs report says some centralized exchange accounts were frozen pending investigation. That is important, but it does not automatically mean every user balance, deposit queue or wrapped-asset route is already clean and final.

CryptoGuide take

The important trust lesson is not that every chain exploit becomes an exchange breach. It is that exchange safety depends on upstream software, bridge design and incident communication quality more than many users admit. The best response is boring discipline: read the chain notice, read the exchange notice, verify the network label, and avoid being the first test transfer after a multi-chain exploit.

FAQ

Did the Cosmos EVM exploit affect centralized exchanges directly?

Not in the sense of an exchange software breach. The August 28, 2026 Cosmos Labs post-mortem says attackers bridged stolen assets off affected chains and sold an estimated additional $2.85 million through centralized exchange accounts, some of which were later frozen.

Which Cosmos EVM versions were affected?

The GitHub advisory says versions below 0.6.2 and versions from 0.7.0 up to but not including 0.7.2 were affected.

What should users wait for before sending funds again?

Wait for both the chain team and your exchange to confirm reopening. A reachable RPC endpoint or wallet page is not enough proof that deposits, withdrawals or bridge routes are fully safe again.

Conclusion

As of Sunday, August 30, 2026, the Cosmos EVM exploit is one of the clearest examples this year of how crypto-exchange trust can fail upstream. If you use exchanges to move assets across Cosmos-linked networks, the practical standard should be higher now: confirm the patched chain version, confirm the venue's network status, confirm the route, and use small verification transfers before treating service as normal again.

Related pages

• Exchange withdrawal protection in 2026
• Zilliqa Ledger incident: what exchange users should check before ZIL transfers resume
• Coinbase July 2026 outage: what exchange users should check
• How crypto exchanges work
• How to verify a legit exchange

Sources

• GitHub Advisory: Balance underflow in EVM StateDB
• Cosmos Labs: Cosmos EVM GHSA-7g4w-cg88-2cq2 post-mortem
• MANTRA Chain: 20th August 2026 full incident post-mortem
• KiiChain release v7.4.0 emergency recovery and EVM precompile fix
• aelf Security Incident Response Progress Update, August 26, 2026