Cosmos EVM, Critical Flaw Without CVE: Six Blockchains Affected, Silent Patch Did Not Stop the Exploit

On August 28, 2026, Cosmos Labs published a GitHub advisory and a post-mortem for a critical vulnerability in the shared Cosmos EVM module, the environment for executing Ethereum-compatible smart contracts in the Cosmos SDK ecosystem. The flaw, identified as GHSA-7g4w-cg88-2cq2, was classified Critical by the vendor but did not receive a CVE identifier, a CWE classification, or a CVSS score. Affected versions are all those prior to 0.6.2 and those between 0.7.0 and 0.7.1. Fixes were released on August 19 in versions v0.6.2 and v0.7.2, but the update is state-breaking and requires a coordinated network upgrade. Between August 20 and 25, the flaw was actively exploited against six blockchains, with estimated economic losses in the millions of dollars.

How the Attack Works: Underflow, Vesting Accounts, and "Inflated" Balances

The vulnerability originates in the code that reconciles EVM state with the x/bank module of the Cosmos SDK. The EVM StateDB tracks only the spendable balance of an account. In vesting accounts, however, the SDK state contains both a spendable balance and a locked balance, which can be delegated through the x/staking module and the staking precompile.

When a vesting account delegates more than its spendable balance, the subsequent write subtracts the entire delegated amount from a smaller balance: the subtraction is not checked and the value underflows, wrapping to approximately 2^256. Subsequent reconciliation mints on a positive delta and burns on a negative delta. An attacker can therefore move a finite amount from an account with a "wrapped" balance and send to a victim an amount equal to 2^256 minus their balance, thereby causing the victim's real funds to be burned upon reconciliation.

On chains running the 0.6.x line, minting or burning occurs on the underlying SDK ledger: a large mint causes a supply overflow that halts the chain. On the 0.7.x line, balances are set directly in x/bank and accept changes that survive the conversion from uint256 to int256. In both cases, the entire operation is executed in a single transaction with a net supply change of zero, starting from a contract deployed at a precomputed address that had previously been converted into a vesting account. Exploitation requires that the chain allows permissionless creation of vesting accounts.

The Timeline: Report in April, Confirmation in August, Silent Patch

The flaw was reported on April 25 through the Cosmos Labs bug bounty program. Initially the team assessed it as posing no risk to funds on live networks: they could not reproduce it on networks with 18 decimals and erroneously concluded that it only affected networks with different decimal configurations. Only on August 13 did confirmation arrive that all Cosmos EVM chains were affected, regardless of decimal configuration.

The primary fix – an underflow guard in the StateDB SubBalance write-back – had already been introduced on the main branch with PR #1176, merged on May 15. Backports came much later: PR #1253 for the v0.6.x line and PR #1254 for v0.7.x, which led to the v0.6.2 and v0.7.2 releases on August 19.

The fix went through the silent patch process, reserved by Cosmos Labs for issues that do not cause loss of funds in production. The policy provides for emergency mitigations or private distribution for immediate risks, but in this case the team considered it safe to proceed silently because the patch was already public on the main branch and no known exploitation was reported.

That assessment proved wrong. On August 20 at 07:16 UTC, eight hours fifteen minutes after the releases were published, a public PR in the Push Chain fork detailed the vulnerability and the exploitation path. Eleven hours fifty minutes later, at 19:06 UTC, the first attack against MANTRA began. The first private notification from Cosmos Labs via secure email went out only on August 21 at 03:36 UTC, about two hours after MANTRA reported the exploitation.

Impact: Six Chains, Millions of Dollars Sold on Exchanges

Cosmos Labs is aware of six blockchains where the exploit was actively used. MANTRA is the only one explicitly named as the first victim. Attackers sold approximately $2.87 million in affected assets on decentralized exchanges, a figure based on August 19 prices and provided by the chains themselves, not independently verified. A further $2.85 million was sold on centralized exchanges, an estimate based on public volume data.

The Cosmos ecosystem includes more than 115 known public blockchains, but Cosmos Labs does not maintain a complete registry of networks running its software. This gap had already forced downstream vendors in July to patch flaws in included filesystems. During the incident, the team discovered eleven Cosmos EVM implementations that had never registered with its security channels.

What Operators Should Do: Patches, Workarounds, and Checks

The official advisory recommends upgrading to v0.6.2 or v0.7.2 or later, applying the change as a coordinated network upgrade because it is state-breaking. If an immediate upgrade is not possible, the recommendation is to halt the chain rather than attempt a coordinated governance upgrade. There is no configuration-only mitigation: disabling the staking precompile removes the primary activation path, but it does not replace the patch.

The Hacker News listed additional operational steps for developers. The first is to close the precondition: reject in the ante handler the MsgCreateVestingAccount, MsgCreatePermanentLockedAccount, and MsgCreatePeriodicVestingAccount messages, without touching vesting accounts defined in genesis. The second is to verify the live code path on a fork: a cherry-pick that fixes only the exported helper can leave an unexported duplicate copy, while all tests continue to pass. The third is to apply the two fixes that the advisory omits: the locked balance snapshot (PR #1187, merged May 20) and the module account guard (commit 3524ebc). The guard unconditionally rejects module accounts, which breaks EVM calls made from a module account. Finally, every team should register a security contact with Cosmos Labs.

ZetaChain ported the three fixes on August 21, noting that the cherry-pick left the live fork path unfixed because the fork contained duplicated unexported helpers. Warden Protocol, two days later, completely blocked the creation of vesting accounts: on Warden, vesting accounts are the only source of locked balances and no functionality depends on their creation, so removing that path closes the precondition without relying on the correctness of the reconstruction.

Silent Patch and Precedents: 37 Vulnerabilities Without Public Description

The advisory documents only one upstream change: the underflow guard of PR #1176. But the same repository contains two other balance fixes not mentioned: PR #1187, which snapshots the locked balance of an account to correctly reconstruct the bank balance after a precompile modification, and commit 3524ebc, titled "Merge commit from fork", which rejects any attempt to set the balance of a module account. Backports of PR #1187 had been opened and merged within twenty-four hours on both release lines, while the backport of PR #1176 followed approximately ninety days later.

The release notes for v0.6.2 and v0.7.2 state that they contain important security fixes, but omit the security backport from the changelogs. The Hacker News confirmed on August 29 that neither release lists the pull requests that carry it.

Cosmos Labs stated that it has silently distributed patches for 37 vulnerabilities over the past 13 months, without downstream developers publicly describing the exploit paths. The decision not to distribute the patch privately after the August 13 confirmation that all chains were affected is now at the center of criticism. The Hacker News contacted Cosmos Labs for comment and is awaiting a response.