Intro
Between August 20 and August 25, 2026, a critical balance-handling bug in the shared Cosmos EVM module was exploited across six blockchains while operators were waiting for a coordinated upgrade window. The advisory, GHSA-7g4w-cg88-2cq2, is rated Critical by Cosmos Labs and shipped without a CVE identifier, a weakness classification, or a CVSS score. The fix landed on August 19 in v0.6.2 and v0.7.2, the post-mortem dropped on August 28, and the window in between is where user funds actually moved out. This Cosmos EVM vulnerability exploit 2026 is not a story about a clever zero-day. It is a story about a known issue that went through a process built for lower-stakes bugs, and a policy that says one thing on paper while doing another in practice.
Background
The original bug report came in on April 25, 2026, submitted through the Cosmos Labs bug bounty program. The early read was wrong. The team tried to reproduce the flaw on 18-decimal networks, could not, and concluded it only affected non-18-decimal chains, a conclusion that did not survive contact with the actual code path. On August 13 the picture changed. Every Cosmos EVM chain was vulnerable regardless of decimal configuration, and that finding collided with the existing Cosmos Labs silent patch policy for non-fund-loss issues. Affected versions are < 0.6.2 and >= 0.7.0 < 0.7.2. The fix in v0.6.2 and v0.7.2 on August 19 is state-breaking, which is why a coordinated halt or hard fork is required rather than a rolling restart. If you have ever had to schedule a maintenance window for a Magento or WordPress site on shared hosting, multiply that by every validator in a proof-of-stake network and you get close to what chain operators are dealing with.
What’s happening now
Six chains were drained between August 20 and August 25. The attacker pattern is a single transaction with net zero supply change, run from a contract deployed onto a precomputed vesting-account address. The technical root cause, in plain terms, is a layering mismatch. The EVM StateDB only tracks spendable balance. Vesting accounts in SDK state carry both spendable and locked balances. Both x/staking and the staking precompile let the locked portion 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. There is no underflow check. The balance wraps to roughly 2^256. Reconciliation then mints on a positive delta and burns on a negative one.
The two divergent failure modes matter. 0.6.x chains mint and burn on the backing SDK ledger, so a large mint causes a supply overflow and halts the chain. 0.7.x chains set balances directly in x/bank and accept changes that survive a uint256-to-int256 conversion, which is why draining rather than halting was the 0.7.x outcome. The precondition most readers will care about is that exploitation requires the chain to allow permissionless vesting-account creation. Chains that close that door in the ante handler can remove the primary trigger path even before upgrading.
What it means in practice
This is the part chain operators should actually read. If you run Cosmos EVM, your decision tree right now is short and not optional: upgrade to v0.6.2 or v0.7.2 in a coordinated network upgrade, halt blocks if you cannot upgrade on the same window, or accept that you are still exposed. There is no configuration-only mitigation. The Hacker News coverage of the post-mortem (opens in new tab) is the cleanest summary I have read of the advisory itself.
The silent patch policy gap is the real story. Cosmos Labs’ own published policy says a network-wide fund-loss risk should trigger private fix distribution or emergency mitigation before public disclosure. The August 19 fix went out as a public silent patch because the code was already on the main branch, and the post-mortem admits that is exactly the kind of case the policy was written to avoid. That mismatch matters for any team that treats Cosmos Labs as a shared dependency. You are trusting a vendor whose published policy and actual practice diverged during a live incident.
There is also a cherry-pick footgun for fork operators. A patch that only updates the exported helper can leave a duplicated unexported copy in the tree, and every test can still pass while the live code path stays vulnerable. If you are forking this module, audit the unexported copy on the actual running binary, not just the test suite. It is the kind of issue that hides in plain sight until someone looks for it on purpose.
How serious is this for a chain I run?
It is Critical and already weaponized. The advisory names six drained chains, the precondition is permissionless vesting-account creation, and the patch is state-breaking, so there is no safe in-place upgrade path.
Can I avoid a coordinated upgrade by changing config or disabling the staking precompile? No. Disabling the staking precompile removes the primary trigger but is not a substitute for the patch, and there is no configuration-only mitigation on the books.
Why did the fix go out as a silent patch if the policy says otherwise? Because the patch was already public on the main branch before the fund-loss risk was confirmed, and the team treated that as overriding the policy threshold. That decision is now the central criticism of the post-mortem.
Do I need to do anything if my chain has no permissionless vesting-account creation? You should still upgrade, but rejecting MsgCreateVestingAccount, MsgCreatePermanentLockedAccount, and MsgCreatePeriodicVestingAccount in the ante handler does close the known trigger path for live accounts. Genesis-defined vesting accounts are not affected by that filter.
What to expect next
I expect scrutiny of the silent patch process itself, not just this one bug. The published policy and the post-mortem are saying different things about when private distribution kicks in, and that gap will be the focus of follow-on coverage and likely a bug bounty policy revision. I expect chain operators on 0.7.x to publish their own reconciliation numbers, since the 0.7.x branch lets drained balances survive uint256-to-int256 conversion rather than halting the chain, which makes the actual loss accounting harder to verify. I expect the advisory to gain a CVE and CVSS score in a future revision, since the current Critical rating is published without either, an unusual posture for a fund-loss advisory in 2026. I expect forks and downstream consumers of the Cosmos EVM module to re-audit their unexported helper copies, because the cherry-pick footgun is the kind of issue that hides in plain sight until someone looks for it on purpose.
What to do tonight
Confirm your binary is on v0.6.2, v0.7.2, or later, and verify it on the running node, not just in your build pipeline. If you are mid-fork, grep for duplicated unexported reconciliation helpers and confirm which copy your live code path actually calls. If you cannot upgrade in the next maintenance window, halt block production rather than running a coordinated governance upgrade, and reject MsgCreateVestingAccount, MsgCreatePermanentLockedAccount, and MsgCreatePeriodicVestingAccount in the ante handler as a stopgap until the patch lands.