Cosmos EVM Vulnerability: $5.72 Million From Six Blockchains and Why Three Chains Had to Halt

If you hold tokens on a smaller blockchain, your balance depends on two things: on that blockchain, and on the software it shares with many others. August made exactly that visible. A flaw in a shared building block called Cosmos EVM was exploited on six blockchains between August 20 and 25, 2026. Around $5.72 million drained away, three chains halted operations, and Cosmos Labs says it contacted 40 networks. On August 28 the team published a post-mortem that describes the sequence openly. This article sets out what happened, why the damage figures in circulation diverge so widely, and what you can check if you hold tokens on an affected chain.

The Cosmos EVM vulnerability at a glance: $5.72 million from six chains

Cosmos EVM is a software module that extends a Cosmos blockchain with an Ethereum-compatible execution environment. A module in this sense is a finished code package that a chain team builds into its own blockchain instead of writing the function itself. The advantage is speed. The price is a shared dependency: a flaw in the module is a flaw in every chain that uses it.

The vulnerability carries the identifier GHSA-7g4w-cg88-2cq2 and is classified as critical by Cosmos Labs itself. According to The Hacker News it was published without a CVE number, without a vulnerability classification and without a CVSS score. Affected are the versions below 0.6.2 as well as those from 0.7.0 up to but not including 0.7.2; the flaw was fixed in v0.6.2 and v0.7.2, which appeared on August 19, 2026.

Not affected is the Cosmos Hub with its token ATOM, which runs without this module. If you are looking for the price page on it, you will find it in our ATOM price prediction. The risk of confusion is real, because the word Cosmos appears in the name of both things, and it explains part of last week's uncertainty.

Balance reconciliation and overflow: how the Cosmos EVM gap works technically

The flaw sits at the seam between two sets of books. A Cosmos blockchain keeps balances in the x/bank module, while the Ethereum environment keeps them in parallel in its own state database, the StateDB. Both have to show the same figure after every transaction, and that reconciliation is where things jammed.

According to The Hacker News, the problem arises when a so-called vesting account delegates more than its freely available balance allows. A vesting account is an address whose tokens are released only on a schedule; part of the holding is locked, part is available. When writing back after the delegation, the code subtracted the full delegated amount from the smaller available amount, without checking whether the result could be positive at all.

What follows is a classic of computer arithmetic. Subtract more from an unsigned number than it contains and it does not go negative but jumps to the top end of its value range. A tiny shortfall turns into a balance on the order of 2 to the power of 256. The attacker could then either withdraw funds from this overflowed account or send another account an amount calculated so that the reconciliation destroyed that account's holding.

What a shared module in a blockchain is

A shared module is program code that several independent blockchains draw from the same source and build into their own software. For you as a holder this means the question of whether your chain is secure cannot be answered from the reputation of its team alone. It also depends on which external building blocks that team uses and how quickly it applies updates.

Why vesting accounts were the way in

Vesting accounts are widespread in young networks, because teams, investors and early contributors usually receive their allocations in stages. They are therefore a regular account type that almost every new chain maintains, not a marginal special case. That is one reason Cosmos Labs recommends, among other things, that affected networks temporarily reject the creation of new vesting accounts.

Four months between report and alarm: the timeline from the post-mortem

The sequence comes from the post-mortem that Cosmos Labs published itself on August 28, 2026, and from the trade reports that evaluated it. It is the actual reason the case is being discussed beyond the individual incident.

On April 25, 2026 the report came in through the bug bounty programme. It was assessed at the time as posing no risk to funds on productive networks. On May 15, according to CryptoSlate, a correction flowed into the main branch as a silent public patch, meaning without being marked as security-critical. On August 13 the team confirmed internally that all Cosmos EVM chains are affected, regardless of their decimal configuration.

On August 19 the corrected versions appeared. On August 20 at 07:16 UTC a first public description of the attack route became accessible; the same day at 19:06 UTC the first unauthorised operation ran on MANTRA. The first private notification of affected chains went out, by this reconstruction, on August 21 at 03:36 UTC, roughly two hours after MANTRA had reported the incident. The public call for validators to halt their chains followed on August 24.

Nominal value versus proceeds: why the damage figures for the Cosmos EVM hack diverge

Anyone reading through the coverage comes across amounts between just under two and well over nine million dollars. That is a question of what is being measured and no contradiction; the distinction is worth making, because it recurs in every exploit report.

The frequently cited sum of around $5.72 million refers to what the attacker actually turned into money: about $2.87 million through decentralised exchanges and about $2.85 million through centralised trading venues, calculated at the rates of August 19. The considerably higher figures, by contrast, represent the nominal value of the drained tokens at the price before the incident.

The difference arises from the selling pressure itself. At KiiChain, according to the report by Protos, the chain names 148,326,583.15 KII as having drained away, with a face value of around nine million dollars, while selling them brought in about 1.6 million. Anyone reading such reports should therefore always check whether the subject is stolen tokens or realised proceeds.

MANTRA, KiiChain and TAC: what happened on the three known chains

Three of the six exploited networks have been named publicly so far. MANTRA halted its chain on August 21 at block 17,449,398 and resumed block production on August 22 with version 8.4.0. Figures between 03:38 and 05:30 UTC are circulating for the restart time; we described the event on August 22 in our report on the MANTRA chain halt and the frozen withdrawal, using the earlier of these two values. The team stated that user balances were not altered and that two addresses under its own control were affected. CryptoSlate, by contrast, puts the MANTRA side of the incident at around $3.6 million in nominal value across 720.9 million tokens. Both figures stand side by side, and we are not smoothing them over.

KiiChain halted at block 9,355,723. By its own account the same technique was applied there eighteen times in succession. TAC stopped on August 22 at block 24,671,475, according to the team after an account had been emptied. In both cases the chain teams traced the cause to the shared Cosmos EVM code rather than to their own logic.

Beyond the three named, Cosmos Labs reported that 13 further potentially affected chains were updated, halted or secured before an attack occurred. Eleven installations of the module were not known to the team at all before the incident and were found only in the course of the review.

The chain halt as an emergency brake: why Cosmos Labs advised validators to stop

A chain halt means validators cease block production; the network processes no more transactions until it restarts in a coordinated way. To outsiders that looks like a loss of control. In this case it was the conservative choice.

The reason lies in the sequence. A regular network upgrade through a governance vote takes hours to days, and during that time the gap would stay open while the attack route was already publicly described. Cosmos Labs therefore advised operators to update immediately to v0.6.2, v0.7.2 or later, and, if that was not immediately possible, to halt block production rather than attempt a coordinated vote. In addition the team recommended rejecting the creation of vesting accounts in the ante handler, checking the fix in exported as well as non-exported code paths, and registering a security contact.

For you as a holder this has a practical consequence that is easily missed: a halted chain is a warning signal about the state of the software, but it is not automatically a signal about your account balance. Whether your holding was altered is a separate matter from whether blocks are currently being produced.

Silent patch and bug bounty: what the case shows about disclosure processes

The programming error itself is undisputed among those involved. What is being debated is the order in which it was made public. A silent patch is the common practice of applying a fix inconspicuously so that attackers do not learn from the notice itself where to strike. This practice works only under one condition: the operators running the code have to know beforehand that they need to act.

KiiChain put this point plainly in its own post-mortem. Publishing a security fix openly before the chains running that code have been informed privately and given time to update, it argued, passes the vulnerability on to anyone who reads the commit. As causes the chain named the lack of advance notice, the failure to mark the fix as critical and the delay in communication. That is the value judgement of an affected party, and we reproduce it as such.

Cosmos Labs points in its own bounty rules to initiating emergency measures where there is immediate or network-wide risk. The post-mortem describes how the standard route for cases without loss of funds was chosen instead. How that assessment came about is the open question the document raises, and it cannot be conclusively judged from outside. The sequence is documented; the evaluation remains a matter for the teams involved.

What holders of affected tokens should check right now

If you hold OM, KII, TAC or another token on a Cosmos EVM chain, the first concern is clarity about the state of things, not a quick reaction in the market. In order.

As a first step, check the network status. A public block explorer for the chain in question shows you whether the block height is still rising or has stopped at a value. If it is standing still, the chain is producing no blocks, and no transaction is confirmed during that time.

As a second step, check the version your chain is running and whether the team has announced a restart on one of the corrected releases. Chain teams usually publish this through their status page or their official channels. If such a statement is missing, that in itself is information.

As a third step, and separately from the above, check whether your trading venue has released deposits and withdrawals for the affected token. These two states are connected but not the same, and that is exactly where most misjudgements arise. If you want to keep your holding available independently of an exchange, the route runs through self-custody; which devices come into question is shown by our comparison of crypto hardware wallets.

Three states you have to keep apart

The first state concerns the chain: is it producing blocks? The second concerns your balance: does your address still show the amount you expect? The third concerns the trading venue: can you deposit and withdraw? A running chain alongside a frozen exchange withdrawal is a common combination, because trading venues decide independently after an incident when to reopen their gateway. Conversely, a halted chain can carry unchanged balances.

How to tell whether a blockchain depends on a shared building block

You can settle this question before buying, and it costs a few minutes. The first indication is the chain's documentation: if it says the chain builds on a framework such as the Cosmos SDK and obtains EVM compatibility through a module, it shares code with other networks.

The second indication is the public code repository. Blockchains as a rule publish their software openly, and the dependency files name which external packages are included in which version. You do not need to be able to read the code; it is enough to see the version number and compare it with the currently recommended one.

The third indication is the communication route. Does the chain have a status page, a security contact and a history of earlier incidents with follow-up analysis? The present case shows how much depends on this: eleven installations of the module were not even known to the publisher, which means it could not have warned their operators in an emergency either. The technical description of the gap can be read in security advisory GHSA-7g4w-cg88-2cq2, and the placing of the timeline in The Hacker News reconstruction.

Tax and evidence: what to document after a chain halt

A network halt is initially no event for tax purposes. As long as nothing about your holding changes, neither a disposal nor a loss you could claim arises. It becomes relevant only once you actually sell in response to the incident, or once tokens disappear from your address.

In practice this means: secure the records now, while they are within reach. That includes screenshots of your account balance with date and time, the transaction identifiers of the operations concerned, your exchange's status notice on the frozen gateway, and the chain team's public statement. If you later close a position at a loss, or have to explain to the tax authorities why a holding no longer exists, the evidence is only as good as what you captured at the moment of the incident.

One note on placing this, because the question comes up regularly: whether a holding lost through an exploit is deductible for tax purposes depends on the individual case and is not settled in blanket terms. This assessment is no substitute for tax advice, and we are not asserting a legal position here that does not exist as such.

Checking the Cosmos EVM vulnerability: what to take away

The case is less a story about a single flaw than one about shared dependencies and about how quickly information reaches its recipients. Three steps you can draw from it:

1. Check the state of your chain and of your exchange separately from each other. Block height in the explorer, balance at your address and gateway status at the trading venue are three readings that measure different things. If in the process you notice that your provider communicates poorly after incidents, our overview of regulated crypto exchanges helps you place it.
2. Before your next purchase, look at which external building blocks a chain uses. Framework, module version and a registered security contact say more about a network's resilience than its announcements do. For storage outside an exchange you will find the options in the comparison of software wallets.
3. Keep holdings you do not actively trade outside anyone else's control. A frozen exchange gateway affects only what is sitting there. Which devices are suitable and what distinguishes them is covered in the hardware wallet comparison.

(As of August 29, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)