Cabinet
Back to Technology Insights
2026.08.28

A Balance-Handling Flaw in cosmos/evm Drained About $5.72M From Six Chains — Twenty Hours From Silent Patch to First Attack

A Balance-Handling Flaw in cosmos/evm Drained About $5.72M From Six Chains — Twenty Hours From Silent Patch to First Attack

What happened

cosmos/evm is the shared module that lets Cosmos SDK chains run Ethereum-style smart contracts. The Cosmos Hub does not run it and was unaffected. What was affected is the set of independent chains that embed it.

Per the Cosmos Labs post-mortem, the attacks ran from 2026-08-20 19:06 UTC to 2026-08-25 15:20 UTC. Exploitation is confirmed on six chains; three — MANTRA, TAC and KiiChain — have been named publicly, and three have not.

Realised losses total about $5.72 million: roughly $2.87 million sold on decentralised exchanges and roughly $2.85 million on centralised exchanges. The post-mortem states explicitly that the former figure is based on 19 August prices, was supplied by the affected chains, and has not been independently audited. The centralised exchange accounts have been frozen pending investigation by the relevant authorities.

Per-chain figures are not measured on a common basis. MANTRA reports roughly 720.9 million tokens, nominally about $3.6 million, moved from two project-controlled wallets, and says user balances were unaffected. KiiChain reports 148,326,583.15 KII drained through eighteen repetitions of the same technique — around $9 million at face value, though selling reportedly netted the attacker about $1.6 million. Adding nominal and realised figures together produces a number that describes nothing; they have to be read separately.

Cosmos Labs rates the vulnerability Critical, but it was published without a CVE identifier, a weakness classification or a CVSS score. Affected versions are below v0.6.2, and v0.7.0 up to but not including v0.7.2. Fixes shipped on 19 August as v0.6.2 and v0.7.2. The upgrade is state-breaking and requires a coordinated network upgrade. Operators unable to upgrade immediately are told to halt the chain rather than attempt a coordinated governance upgrade.

The conditions that made it work, in sequence

Technically, the flaw sits at the intersection of two design decisions: that Cosmos SDK lets an account be given vesting status after the fact, and that on the EVM side a balance is also written through a path separate from the bank module.

According to KiiChain's report, the attacker fixed in advance the address its exploit contract would deploy to, converted that address into a vesting account, and then placed the contract there. The contract existed carrying inherited vesting status. Because a vesting account holds a balance it cannot spend, delegating one wei more than the spendable balance caused the mirrored EVM-side balance to wrap around the unsigned lower bound, producing a value near 2^256. Total supply was never inflated, and each drain was capped at the victim's real balance. An ordinary wallet cannot reach this path, because it cannot delegate more than it can spend.

Put differently, this is not a mint-from-nothing attack. It is an inconsistency arising from a design in which one balance is recorded in two places and those two places are written separately. The v0.6.2 and v0.7.2 changelogs list: contract creation bumps the sender's nonce; SetAccount persists nonce and balance together; and the EVM commit path may fail to write a module account's balance. The shape of the fix reveals the shape of the cause.

KiiChain states that every cosmos/evm chain with vesting accounts enabled carries the same exposure — which, it argues, is why MANTRA and TAC were compromised the same week by the same class of attack.

The timeline runs as follows. 25 April 2026: reported through the bug bounty programme. Cosmos Labs' testers could not reproduce it against known production configurations and concluded funds on live networks were not at risk. On that basis the fix was handled as a public patch not marked security-critical, rather than privately distributed to affected chains. Early August: independent researcher reports established that all cosmos/evm chains were affected. 19 August: patched releases published, with the fix deliberately obscured to hinder reverse engineering; the release notes say only that they contain important security fixes, and the changelogs omit the backport. 20 August 07:16 UTC: a public pull request in Push Chain's fork described the vulnerability and its exploitation path in detail, attributed the finding to an independent audit, listed which released tags remained vulnerable, and stated that upgrading to a released tag would not remediate the issue. 20 August 19:06 UTC: the first attack.

Comparison and the general lesson

What lifts this above an individual bug is that the disclosure process itself is the point of contention.

MANTRA's post-mortem states that twenty hours was not a realistic window in which to assess, build, test and coordinate a state-breaking upgrade across 38 independent validators, particularly without a vulnerability-specific advisory. The company has formally raised the delay with the Cosmos maintainers and is seeking clearer disclosure practices and defined backport expectations for security-relevant fixes. KiiChain argues the instruction mattered more than the code: a patch takes days to review, build, test and roll out across a validator set, while a halt takes minutes.

Cosmos Labs' position is on the record too. The post-mortem says the company has released patches for 37 vulnerabilities silently over the past thirteen months without downstream developers precisely describing exploit paths in public. The public description in Push Chain's fork did appear twelve hours before the first attack. The ordering nonetheless stands: patch on 19 August, public description at 07:16 UTC on 20 August, first attack at 19:06 UTC the same day.

Generalised: silent patching works when the number of downstream implementations is small, the update is non-breaking, and applying it is fast. cosmos/evm meets none of those conditions. The Cosmos ecosystem spans more than 115 public chains and Cosmos Labs does not maintain a complete registry of them; the response uncovered eleven cosmos/evm deployments that had never been registered with the team. The update is state-breaking and requires validator coordination. Under those conditions, publishing a patch is not a defence — it can become the starting point for reverse engineering.

The response was not ineffective, though. Cosmos Labs coordinated with 40 chains and helped 13 networks patch or halt before they were attacked. What was lost was the moment at which that coordination began.

Pitfalls to watch

First, the flaw is in the shared module, not in any individual chain's code, so auditing your own codebase will not find it. KiiChain stated plainly that the vulnerability is in Cosmos code rather than KiiChain code, and sits in the shared module the chain runs unmodified. Running a dependency unmodified is an explanation of exposure, not a defence against it.

Second, per KiiChain's report, two of the three underlying defects remain unfixed upstream. Upgrading to v0.6.2 or v0.7.2 may be necessary without being sufficient. "We've upgraded" should not be read as "we're done."

Third, release notes that say only "important security fixes" while the changelog omits the relevant pull requests are not an exception here — the company's own figure of 37 makes that clear. Any process that decides on dependency upgrades purely from changelog content will structurally miss this class of fix.

Fourth, designs that assume emergency changes go through a governance proposal cannot move fast enough for this kind of event. Cosmos Labs itself advises halting rather than proposing. A chain without a rehearsed halt procedure has one fewer option available.

[Technical Insights & Actions]

  1. For a shared module, once three conditions coincide — many downstream implementations, a breaking update, and slow application — publishing the fix inverts into publishing the attack. Silent patching only works while all three are small. Dependencies you run unmodified fall out of audit scope most easily, and are exactly the ones exposed to the upstream's disclosure policy. [Platform / infrastructure owners] During September, enumerate the external dependencies you run unmodified in production and, for each, establish whether the upstream distributes security fixes privately or as public patches, and whether it issues a separate security advisory. Classify those that do neither as high risk.
  2. Any design in which a single value such as a balance is held in two representations with separate write paths can produce a state where only one side is updated. The fix here took the form of persisting nonce and balance together precisely because consistency had to be guaranteed at the write boundary. Every implementation that layers an EVM-compatible surface over another state machine carries the same structure. [Protocol and contract developers] Identify the places in your stack where one value has multiple representations (balances, nonces, permission flags) and review, by the next regular release, whether writes are atomic and whether any path can update only one side.
  3. With an update that carries no security advisory, you cannot learn more than the release notes say. The speed of your upgrade decision therefore improves only by shortening your own halt-and-upgrade time, not by hoping for better disclosure. A team able to run a state-breaking upgrade in twenty hours would have had a different outcome. [Node operators / validators] Measure the actual time required for an emergency halt and for a state-breaking upgrade. If it exceeds 24 hours, first establish an emergency halt procedure that bypasses governance proposals, and agree it with the validator set.

[Sources]

This article is a technical commentary based on publicly available information and is not investment advice.