# Critical Cosmos EVM Vulnerability Exposed Across Multiple Blockchains in August 2026
A severe balance-handling flaw in the shared Cosmos EVM module allowed attackers to drain funds from six separate blockchains during a five-day window in late August 2026. The vulnerability, identified by Cosmos Labs as GHSA-7g4w-cg88-2cq2, has raised serious questions about the speed and transparency of the patch distribution process across the ecosystem.
## How the Flaw Works
The vulnerability exists in the code layer that synchronizes Ethereum Virtual Machine (EVM) state with the Cosmos SDK’s `x/bank` module. The core issue lies in how vesting accounts are handled during delegation operations.
In the EVM environment, the `StateDB` tracks only an account’s spendable balance. However, vesting accounts within SDK state maintain two separate figures — a spendable balance and a locked balance. Both the `x/staking` module and the staking precompile allow the locked portion to be delegated as collateral.
When a vesting account delegates more than its available spendable balance, the system performs a post-delegation write-back that subtracts the full delegated amount from the smaller spendable figure. This subtraction carries no underflow protection. When the spendable balance is exceeded, the result wraps to approximately 2^256, creating a massive artificial balance.
The reconciliation process then interprets this wrapped value as a positive delta, minting tokens to restore the ledger to match the inflated state. An attacker can either extract funds from the wrapped account directly or target a victim account by sending it 2^256 minus its actual balance, causing the reconciliation to burn the victim’s genuine holdings in the process.
## Affected Chains and Versions
Two distinct release lines were compromised:
– **Versions prior to 0.6.2** — these chains mint and burn tokens on the backing SDK ledger, meaning a large mint operation triggers a supply overflow that halts block production entirely.
– **Versions 0.7.0 through 0.7.1** — these chains write balances directly into `x/bank` and accept balance changes that persist through a uint256-to-int256 conversion, creating a different exploitation pathway.
Both halves of the attack execute within a single transaction and result in a net supply change of zero, making the exploit difficult to detect through standard monitoring. The attack contract was deployed onto a precomputed address and the attacker first converted that address into a vesting account. This means chains that allowed permissionless vesting-account creation were particularly vulnerable.
## Timeline of Disclosure and Response
The vulnerability was first reported through Cosmos Labs’ bug bounty program on April 25, 2026. At the time of initial assessment, the team concluded the flaw posed no risk to funds on live networks. The reasoning was based on a mistaken belief that the vulnerability only affected non-18-decimal token networks — it could not be reproduced on 18-decimal configurations.
By August 13, the team confirmed that all Cosmos EVM chains were affected regardless of their decimal configuration. Despite this critical escalation, the fix was distributed through the same public silent patch process the company typically reserves for issues that do not cause fund loss on production networks.
The patches — version 0.6.2 and version 0.7.2 — were released on August 19. A public pull request in Push Chain’s fork detailed the vulnerability and its exploitation path at 07:16 UTC on August 20, roughly eight hours after the releases went out. The first real-world attack, targeting the MANTRA chain, began at 19:06 UTC that same day — eleven hours and fifty minutes after the patches were available. Cosmos Labs sent its first private notification by secure email at 03:36 UTC on August 21, approximately two hours after MANTRA confirmed it had been exploited.
## The Patch Distribution Gap
Cosmos Labs’ own published bug bounty policy, last updated on July 27, states that when a vulnerability presents an immediate or network-wide risk, the company should initiate emergency mitigations, private fix distribution, or coordinated upgrades before any public disclosure occurs. The company acknowledged that it deviated from this protocol, explaining that the patch had already been publicly available on the main branch without known exploitation at the time of the decision.
This decision has drawn criticism within the community, as affected chain operators had only hours between the public release and the first confirmed attack. Several chains that were running vulnerable versions but had not yet registered a security contact with Cosmos Labs were caught off guard.
## Recommended Actions for Chain Operators
The advisory outlines several steps that operators of Cosmos EVM chains should take immediately:
1. **Upgrade** to v0.6.2, v0.7.2, or any later release. Because the fix is state-breaking, it must be applied as a coordinated network upgrade across all validating nodes.
2. **Halt block production rather than attempting a governance vote.** The advisory explicitly states there is no configuration-only workaround and that disabling the staking precompile alone removes the primary trigger but does not address the root cause. Chains that cannot upgrade simultaneously are advised to stop producing blocks.
3. **Close the precondition** by rejecting `MsgCreateVestingAccount`, `MsgCreatePermanentLockedAccount`, and `MsgCreatePeriodicVestingAccount` transactions in the ante handler. Vesting accounts that already exist in genesis state remain unaffected.
4. **Verify the live code path on forks carefully.** A cherry-pick that only patches the exported helper function can leave a duplicated unexported copy untouched while every test still passes, creating a false sense of security.
5. **Apply two additional fixes that the original advisory omitted.** A locked-balance snapshot and a module-account guard are separate changes. The module-account guard rejects module accounts unconditionally, which can break EVM calls made from module accounts and requires additional evaluation.
6. **Register a security contact** with Cosmos Labs. During the incident, the company discovered that eleven Cosmos EVM deployments had never registered with its security channels.
## The Silent Patch Problem
An additional layer of complexity emerged around how the upstream changes were propagated. The primary fix — an underflow guard on `SubBalance` — was merged into the main branch on May 15 as pull request #1176 and was not backported until August 13, a delay of roughly ninety days.
Two other critical fixes existed in the same repository. Pull request #1187, merged May 20, introduced a mechanism that snapshots an account’s locked balance so that the bank balance can be reconstructed correctly after a precompile modifies it. Backports for #1187 to both release lines were opened and merged within twenty-four hours, yet the backport for #1176 followed a much slower timeline.
Additionally, a commit identified as `3524ebc`, titled “Merge commit from fork,” introduced a guard that rejects any attempt to set the balance of a module account unconditionally. ZetaChain contributor morde08 highlighted that when forks cherry-picked only the exported patch, they often left duplicate unexported helpers in place, meaning the live execution path remained vulnerable even though the publicly visible code appeared patched.
## Financial Impact
Attackers liquidated approximately USD 2.87 million in affected assets through decentralised exchanges, using prices from August 19 as the baseline for valuation — a figure supplied by the affected chains and not independently audited by Cosmos Labs. An additional USD 2.85 million was moved through centralised exchanges, an estimate Cosmos Labs derived from publicly available volume data.
## Ecosystem-Wide Visibility Gaps
The Cosmos ecosystem encompasses over 115 known public blockchains, yet Cosmos Labs acknowledged it does not maintain a complete registry of the networks running its software. This same visibility gap was implicated in a separate incident in July where downstream vendors had to patch bundled filesystem flaws without receiving timely notification from the upstream provider.
Warden Protocol took a particularly aggressive defensive approach, blocking vesting-account creation entirely. “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,” explained Warden Protocol contributor jlehtimaki.
—
## Frequently Asked Questions (FAQ)
### What is Cosmos EVM?
Cosmos EVM is a shared module that enables Ethereum Virtual Machine compatibility within the Cosmos SDK ecosystem. It allows developers to deploy EVM-compatible smart contracts on Cosmos-based blockchains, bridging the two major blockchain development frameworks.
### Why wasn’t this vulnerability assigned a CVE identifier?
The flaw, designated GHSA-7g4w-cg88-2cq2, was published by Cosmos Labs without a CVE identifier, a formal weakness classification, or a CVSS score. The reasons for this decision have not been publicly explained by Cosmos Labs.
### What makes this vulnerability particularly dangerous?
The flaw allows attackers to manipulate account balances through arithmetic underflow in vesting account delegation operations. Because the attack occurs within a single transaction with a net supply change of zero, it evades many standard monitoring and alerting systems.
### Were all Cosmos EVM chains affected?
Yes. Cosmos Labs confirmed by August 13 that all Cosmos EVM chains were vulnerable regardless of their token decimal configuration. This contradicted the initial assessment from April, which incorrectly assumed only non-18-decimal networks were at risk.
### Is disabling the staking precompile sufficient as a fix?
No. While disabling the staking precompile removes the primary trigger path, it does not address the underlying balance-handling flaw. The advisory explicitly warns against treating this as a substitute for the full patch.
### What is a “silent patch process”?
The silent patch process is Cosmos Labs’ method of distributing security fixes publicly on the main branch without coordinating private disclosure with affected downstream vendors. The company typically reserves this approach for issues that do not cause fund loss on production networks, making its use for a critical fund-threat vulnerability a point of controversy.
### How can chain operators protect themselves if they cannot upgrade immediately?
The advisory recommends halting block production rather than attempting a coordinated governance upgrade. Operators should also close the precondition by rejecting vesting-account creation messages in the ante handler and verify that their live code paths are fully patched, including any duplicated unexported helper functions.
### What caused the delayed backport of the primary fix?
The underflow guard on `SubBalance` (PR #1176) was merged to the main branch in May 2026 but was not backported to the release lines until August 2026 — a roughly ninety-day gap. The reasons for this delay have not been publicly detailed.
—
## Conclusion
The Cosmos EVM vulnerability of August 2026 exposes fundamental challenges in how security patches are distributed across decentralized blockchain ecosystems. A critical flaw that threatened user funds across six chains was disclosed through a public, rather than private, channel — a decision that departed from the company’s own emergency response policy and left downstream operators with an uncomfortably narrow window to protect their networks.
The incident also highlights the dangers of incomplete backporting practices. Multiple fixes existed in the upstream repository, but the slow and uneven propagation of these changes meant that some chains remained vulnerable even after applying what they believed was the full patch. The lesson for any project maintaining shared infrastructure is clear: a partial fix is not a fix at all.
For the broader Cosmos ecosystem, the event underscores the need for complete registries of networks running shared software, standardized security contact channels, and coordinated response protocols that prioritize fund safety over release process convenience. As the ecosystem continues to grow — now spanning over 115 public blockchains — the cost of these coordination gaps will only multiply.
Thank you for reading
