Cosmos EVM Flaw Drained Six Blockchains After a Silent Patch Tipped Off Attackers

Cosmos Labs has confirmed that a critical flaw in the shared Cosmos EVM module, tracked as GHSA-7g4w-cg88-2cq2, was exploited to drain roughly $5.72 million from six separate blockchains between August 20 and 25, 2026.

The advisory carries no CVE, no CWE, and no CVSS score, yet Cosmos Labs rated it Critical. The reason it matters well beyond crypto: the bug did not live in any single chain. It lived in a component that dozens of Cosmos SDK networks embed to gain Ethereum compatibility, so one balance-handling defect became a shared liability the moment it was understood. According to The Hacker News and a Cosmos security post-mortem reported by CryptoSlate, Cosmos Labs contacted 40 networks after the attacks began, and 13 other potentially exposed chains patched, halted, or applied mitigations before they were hit.

A Bug Reported in April, Exploited in August

The timeline is the story here, and it is not flattering. Cosmos Labs says the vulnerability was first reported through its bug bounty program on April 25, 2026. After testing, engineers concluded it affected only networks that used a non-standard token-decimal configuration, while known production Cosmos EVM chains used the standard 18-decimal setup. On that basis, the flaw was judged unlikely to threaten live funds.

That assessment shaped everything that followed. Because the team believed deployed chains were safe, it handled the fix as a quiet public patch rather than a private, coordinated security release. As the post-mortem put it, in a line worth reading twice: "Based on that assessment, Cosmos Labs addressed the vulnerability through its silent, public patch process rather than the private patch distribution process used when a vulnerability is believed to threaten live user funds." The fix was merged into the main codebase on May 15 and was not immediately backported to older release branches, because the change was state-breaking and required coordinated network upgrades.

In early August, further research overturned the original conclusion: Cosmos EVM deployments were vulnerable regardless of their decimal configuration. Patched releases v0.6.2 and v0.7.2 shipped late on August 19. Within roughly 12 hours, a public pull request in another project's fork described the flaw and its exploitation path, and the first unauthorized transaction on MANTRA followed. The patch that was supposed to close the door instead advertised where the door was, before most operators had walked through it.

The official advisory is blunt about the options for anyone still exposed. Its verbatim guidance: "If an operator cannot upgrade immediately, halt the chain rather than attempt a coordinated governance upgrade." There is, the advisory states plainly, no configuration-only mitigation.

Which Chains Were Hit, and What Was Lost

Cosmos Labs' post-mortem names MANTRA, TAC, and KiiChain among the six exploited networks, and TronWeekly additionally cites Nesa. The full roster of all six chains has not been enumerated in the public reporting I could verify, so treat the complete list as not yet confirmed. What is consistent across sources is the shape of the theft: attackers moved funds out through two routes, roughly $2.87 million bridged and sold through decentralized exchanges and roughly $2.85 million routed through centralized venues, whose linked accounts have since been frozen.

MANTRA absorbed the largest publicly detailed hit. Per CryptoSlate's account of the post-mortem, an unprivileged wallet moved about 720.9 million tokens from two addresses that had not authorized the August 20 transactions, without compromising any validator, administrator, governance, or multisig keys. That last detail is the one defenders should sit with: this was not a stolen-key incident. Previously inert balances simply became transferable, and the project valued the movement at roughly $3.6 million using the pre-incident price. MANTRA later acknowledged that its own monitoring failed to flag the first transaction for almost four hours because it treated the source as an address incapable of moving funds.

Recovery, as of the August 28 disclosure, is unconfirmed and looks partial at best. Cosmos Labs reported that no MANTRA tokens had been recovered, that about 38 million remained immobilized in the attacker's account, and that the remainder had been traced through exchange routes and referred to platforms and law enforcement. Frozen is not recovered, and none of the affected communities should be described as made whole yet.

One question readers keep asking: were the large Cosmos ecosystem hubs affected? The named victims are smaller Cosmos EVM chains, and I have seen no confirmation that Cosmos Hub or Osmosis run the vulnerable module or were among the exploited networks. Their exposure is unconfirmed either way, so I am flagging it rather than asserting safety. The affected surface is the optional Cosmos EVM module and its staking-related pathway, not the base Cosmos SDK that every chain shares.

My Read: A Shared Module Is a Shared Blast Radius

My read (assessment, not reported fact): the dollar figure is the least interesting number in this incident. The number that should worry security teams is 40, the count of networks Cosmos Labs had to contact once the real scope was understood, plus the 11 previously unknown deployments the response surfaced. When many independent products embed the same module, a triage mistake in one place is not contained to one place. It is a latent liability sitting inside every downstream chain, waiting for the moment someone reproduces it.

This is the same structural problem we have covered in software supply chains, just wearing a blockchain costume. It rhymes with the Shai-Hulud open-source package attacks, where a compromise in shared npm dependencies propagated into everything that pulled them, and with OpenAI's post-mortem on the Hugging Face breach, which framed a shared-infrastructure failure as a systemic warning shot. The lesson repeats: a dependency you did not write is still a dependency you have to defend, and a "low risk" rating on an upstream advisory is a claim to verify against your own configuration, not a permission slip to stop tracking it. This is exactly why disciplined vulnerability management treats third-party and open-source components as first-class assets rather than someone else's problem.

The silent-patch decision compounds the module problem. A quiet fix on a public repository is not private. It is a countdown. Anyone watching the commit history of a widely used component can reverse a "state-breaking" balance fix into an exploitation path, which is precisely what happened here inside a day. For defenders downstream, that means the window between an upstream patch and in-the-wild exploitation can be hours, not weeks.

What Cosmos Is Changing, and What to Demand Upstream

Cosmos Labs says it is revising its vulnerability triage and disclosure procedures after a flaw it once judged unlikely to threaten production ultimately reached six networks and forced emergency action across dozens more, per CryptoSlate. The specific failure it has admitted is instructive: engineers could not reproduce the issue on standard 18-decimal networks in April and generalized that negative result into a conclusion that live chains were safe. A negative test became a safety claim, and the safety claim justified the quieter patch path.

For any team that depends on a shared upstream component, that is the transferable lesson. You cannot outsource your risk judgment to the maintainer's severity label, because the maintainer is reasoning about the general case while you are running a specific configuration. Ask upstream projects how they classify and communicate fixes, watch for state-breaking or security-adjacent commits even when they ship quietly, and treat a downgraded severity as a prompt to test in your own environment rather than a reason to stop looking. The chains that patched or halted before August 20 did exactly that, which is why 13 potential victims are a footnote here instead of a headline.

What Cosmos EVM Chain Operators Should Do Now

If you run a chain that integrates the cosmos/evm module, or you are unsure whether one of your deployments does, treat this as an active-exploitation event and work the following list. The first two items are time-sensitive.

Upgrade immediately to v0.6.2 or v0.7.2 (or later); the change is state-breaking, so plan the coordinated upgrade now and, if you cannot execute it right away, halt the chain rather than run exposed. Then audit your balance-state history across the August 20 to 25 window, paying specific attention to transfers originating from burn addresses, genesis-era accounts, or any address your team assumed could not move funds. Monitor treasury, bridge, and exchange outflows in near real time, and remove the assumption that a "dormant" address is safe to ignore in your alerting. Finally, coordinate directly with Cosmos Labs through its security channel so your response feeds the broader ecosystem effort rather than running blind.

Defender checklist for operators of chains that embed the shared Cosmos EVM module, built from the GHSA-7g4w-cg88-2cq2 advisory and the August 28, 2026 post-mortem.

None of this is exotic incident-response work. It is the same discipline any team owes a critical dependency: patch on the vendor's clock, hunt for the specific behavior the flaw enables, and assume that "we were told it was low risk" is a hypothesis about your environment, not a finding.

Primary Documents

• GitHub Security Advisory GHSA-7g4w-cg88-2cq2, "Balance underflow in EVM StateDB" (Critical; no CVE; patched in v0.6.2 and v0.7.2).
• The Hacker News, reporting on the Cosmos EVM exploitation and disclosure timeline.
• CryptoSlate, on the Cosmos Labs post-mortem, the misjudged triage, and per-chain losses.