Cosmos Labs has warned that a critical balance-handling flaw in the shared Cosmos EVM module was exploited to drain funds from six blockchains between August 20 and August 25, 2026.

The vulnerability, designated GHSA-7g4w-cg88-2cq2, is rated Critical by Cosmos Labs and was published without a CVE identifier, a weakness classification, or a CVSS score.

Affected versions are < 0.6.2 and >= 0.7.0 < 0.7.2, and the fix shipped in v0.6.2 and v0.7.2 on August 19. Chain operators are told to upgrade to one of those releases or later, a change that is state-breaking and requires a coordinated network upgrade.

Operators who cannot upgrade immediately are told to halt the chain rather than attempt a coordinated governance upgrade.

In a post-mortem published August 28, Cosmos Labs said the flaw was reported through its bug bounty program on April 25 and was assessed at the time as posing no risk to funds on live networks.

"We were unable to reproduce the vulnerability on 18-decimal networks and incorrectly concluded that it affected only non-18-decimal networks," Cosmos Labs said in the post-mortem.

The team confirmed by August 13 that all Cosmos EVM chains were affected regardless of decimal configuration. The fix was then routed through the same public silent patch process the company reserves for issues that do not cause fund loss on production chains.

"At this point, for a vulnerability that is known to threaten user funds in production networks, the team would typically use secure channels to distribute a patch privately to the affected networks. Because the patch had already been publicly available on the main branch without known exploitation, the team concluded that it would be safe to proceed with the silent patch process," Cosmos Labs said.

The company's own published silent patch policy sets a different course for a flaw of that class.

"When an issue presents an immediate or network-wide risk, Cosmos Labs will initiate emergency mitigations, private fix distribution, or coordinated upgrades before any public disclosure occurs," Cosmos Labs said in its bug bounty policy, last synced on July 27.

The flaw sits in the code that reconciles Ethereum Virtual Machine (EVM) state with the Cosmos SDK x/bank module. The EVM StateDB tracks only an account's spendable balance, while vesting accounts in SDK state hold both a spendable and a locked balance, and both x/staking and the staking precompile permit the locked portion to be delegated.

When a vesting account delegates more than its spendable balance, the post-delegation write-back subtracts the full delegated amount from the smaller spendable figure. The subtraction is unchecked, and the balance wraps to roughly 2^256.

Reconciliation then mints on a positive delta and burns on a negative one. The attacker can move a finite amount out of the wrapped account, or send a victim account 2^256 minus its balance so that reconciliation burns the victim's real holdings.

Chains on 0.6.x mint and burn on the backing SDK ledger, so a large mint causes a supply overflow that halts the chain. Chains running 0.7.x set balances directly in x/bank and accept changes that survive a uint256 to int256 conversion.

Both halves run inside a single transaction with a net supply change of zero, from a contract deployed onto a precomputed address that was first turned into a vesting account. Exploitation requires the chain to permit permissionless vesting-account creation.

Operators running Cosmos EVM are advised to take the following steps -

• Upgrade to v0.6.2 or v0.7.2 or later, applying it as a coordinated network upgrade because the change is state-breaking.
• Halt rather than vote. Chains that cannot upgrade at once are told to stop block production instead of running a coordinated governance upgrade. The advisory states there is no configuration-only mitigation, and that disabling the staking precompile removes the primary trigger path but is not a substitute for the patch.
• Close the precondition. Reject MsgCreateVestingAccount, MsgCreatePermanentLockedAccount, and MsgCreatePeriodicVestingAccount in the ante handler. Vesting accounts defined in genesis are unaffected.
• Verify the live code path on a fork. A cherry-pick that patches only the exported helper can leave a duplicated unexported copy in place while every test still passes.
• Apply the two fixes the advisory omits. The locked-balance snapshot and the module-account guard are separate changes, and the module-account guard rejects module accounts unconditionally, which breaks EVM calls made from a module account.
• Register a security contact with Cosmos Labs, which learned of eleven Cosmos EVM deployments during the incident that had never registered with its security channels.

The advisory documents one upstream change, the SubBalance underflow guard merged to main on May 15 as pull request #1176 and backported on August 13. Two further balance fixes sit in the same repository and are named nowhere in it.

Pull request #1187, merged May 20, snapshots an account's locked balance so the bank balance is reconstructed correctly after a precompile changes it. Backports of #1187 to both release lines were opened the same day and merged within twenty-four hours, while the backport of #1176, an equally state-breaking change, followed about ninety days later.

Commit 3524ebc, titled "Merge commit from fork", rejects any attempt to set the balance of a module account.

ZetaChain contributor morde08 said in a port of all three fixes published August 21 that the cherry-picked patch left the fork's live path unpatched, because the fork carried duplicate unexported helpers while the upstream change touched only the exported one.

Warden Protocol took the other route two days later and blocked vesting-account creation outright.

"Vesting accounts are the only source of locked balances on Warden and nothing depends on users being able to create them, so removing that path closes the precondition rather than relying on the reconstruction being correct," Warden Protocol contributor jlehtimaki said in a commit message.

A public pull request in Push Chain's fork of Cosmos EVM described the vulnerability and its exploitation path in detail at 07:16 UTC on August 20, eight hours and fifteen minutes after the releases went out.

The first attack, against MANTRA, began eleven hours and fifty minutes later at 19:06 UTC. Cosmos Labs sent its first private notification by secure email at 03:36 UTC on August 21, roughly two hours after MANTRA reported that it had been exploited.

"Cosmos Labs has released patches for 37 vulnerabilities silently in the last 13 months without downstream developers precisely describing exploit paths in public," Cosmos Labs said in the post-mortem.

The v0.6.2 and v0.7.2 release notes both state that the release contains important security fixes and should be applied as soon as possible, and both omit the security backport from their changelogs. The Hacker News confirmed on August 29 that neither release lists the pull requests carrying it.

Cosmos Labs said it is aware of six chains on which the exploit was leveraged.

Attackers sold approximately USD 2.87 million in affected assets on decentralised exchanges based on August 19 prices, a figure the company said was supplied by the affected chains and has not been independently audited. A further USD 2.85 million was sold on centralised exchanges, an estimate Cosmos Labs based on publicly available volume data.

The Cosmos ecosystem spans over 115 known public blockchains, and the company said it holds no complete registry of the networks running its software, the same gap that left downstream vendors to patch bundled filesystem flaws in July.

The Hacker News has reached out to Cosmos Labs for comment on why the patch was not distributed privately after the team confirmed that all chains were affected, and will update this story with any response.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.