"We were unable to reproduce the vulnerability on 18‑decimal networks and incorrectly concluded that it affected only non‑18‑decimal networks," Cosmos Labs wrote in a post‑mortem published August 28.
Cosmos Labs' timeline: disclosure, misclassification, and confirmation
Cosmos Labs says the bug was reported through its bug bounty program on April 25, 2026, and initially assessed as posing no risk to funds on live networks. By August 13 the team had confirmed that every Cosmos EVM deployment was vulnerable regardless of decimal configuration. A fix was merged into main and released as v0.6.2 and v0.7.2 on August 19, 2026; those releases were state‑breaking and required coordinated network upgrades. Cosmos Labs sent a first private notification by secure email at 03:36 UTC on August 21, roughly two hours after MANTRA reported an exploitation at 19:06 UTC on August 20.
How the bug works: StateDB, vesting accounts and an unchecked subtraction that wraps to ~2^256
The flaw (GHSA‑7g4w‑cg88‑2cq2) lives in the reconciliation between the EVM StateDB and the Cosmos SDK x/bank module. The EVM StateDB tracks only an account's spendable balance while SDK vesting accounts contain both spendable and locked balances; 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 value. That subtraction is unchecked and can wrap to roughly 2^256.
Reconciliation then mints on a positive delta and burns on a negative one. Chains on v0.6.x perform mint and burn operations on the backing SDK ledger and can experience a supply overflow that halts the chain; chains on v0.7.x set balances directly and accept changes that survive a uint256→int256 conversion. Exploitation required two conditions together: permissionless creation of vesting accounts and the chain's runtime behavior for balance writes—all executed within a single transaction originating from a contract deployed to a precomputed address that was turned into a vesting account.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadObserved exploitation and financial impact
Cosmos Labs says the flaw was exploited to drain funds from six blockchains between August 20 and August 25, 2026. The company reports attackers sold approximately USD 2.87 million in affected assets on decentralized exchanges (priced at August 19) and an estimated USD 2.85 million on centralized exchanges; Cosmos Labs attributes these figures to the affected chains and publicly available volume data and notes they have not been independently audited. The Hacker News confirmed on August 29 that the v0.6.2 and v0.7.2 release notes omit the security backports and do not list the pull requests that carry the fixes.
Patches, policy choices, and operator guidance
Cosmos Labs rates the flaw Critical and published fixes in v0.6.2 and v0.7.2 on August 19. The company says it routed the fix through its "public silent patch" process because the patch had already been publicly available on the main branch and there was no known exploitation at the time that route was chosen. That decision conflicts with the company's own bug bounty policy, last synced July 27, which instructs that "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."
Operators running Cosmos EVM are advised to upgrade to v0.6.2 or v0.7.2 or later via a coordinated, state‑breaking network upgrade. If a chain cannot upgrade immediately, Cosmos Labs instructs operators to halt block production rather than attempt a governance upgrade. The advisory also lists operational and code mitigations: reject MsgCreateVestingAccount, MsgCreatePermanentLockedAccount, and MsgCreatePeriodicVestingAccount in the ante handler to close the precondition; disabling the staking precompile removes the primary trigger path but is not a substitute for the patch; verify live code paths on a fork because cherry‑picks can leave duplicate unexported helpers unpatched; and apply the two additional fixes the advisory notes were omitted from the release (the locked‑balance snapshot and the module‑account guard).
ZetaChain, Warden Protocol and Push Chain: immediate forks and mitigations
Downstream projects took different approaches. A ZetaChain contributor, morde08, said in a port of all three fixes published August 21 that a 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 helper. Warden Protocol blocked vesting‑account creation outright on August 23; contributor jlehtimaki explained in a commit message that "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." Push Chain published a public pull request describing the vulnerability and exploitation path at 07:16 UTC on August 20, eight hours and fifteen minutes after the upstream releases went out.
Cosmos Labs says it discovered eleven Cosmos EVM deployments during the incident that had never registered security contacts with the project. The company also notes the Cosmos ecosystem spans over 115 known public blockchains and that it does not hold a complete registry of networks running its software—an absence that contributed to the uneven downstream response during this incident.
Cosmos Labs published a post‑mortem on August 28 and lists a series of concrete, immediate measures for operators; the record shows the vulnerability was known in April, reclassified in August, patched publicly on August 19, and exploited across multiple chains beginning August 20. The facts leave open a central operational question: why a privately distributed emergency patch was not chosen once the team concluded the bug threatened funds on all deployments, even as forks and individual operators scrambled to close the precondition and mitigate loss.
