**Cosmos Labs** has issued a stark warning regarding a critical balance-handling flaw within its shared **Cosmos EVM** module. This vulnerability, identified as **GHSA-7g4w-cg88-2cq2**, was exploited to siphon funds from six different blockchains over a five-day period, from August 20 to August 25, 2026. ### The Vulnerability and Its Underestimation The flaw, rated Critical by **Cosmos Labs**, was published without a **CVE** identifier, a formal weakness classification, or a **CVSS** score. Affected versions include `< 0.6.2` and `>= 0.7.0 < 0.7.2`. In a [post-mortem published August 28](https://github.com/cosmos/security/blob/main/communications/cosmos_evm_GHSA-7g4w-cg88-2cq2_post_mortem.md), **Cosmos Labs** revealed that the vulnerability was reported through its bug bounty program on April 25. At the time, it was incorrectly assessed 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** stated in the post-mortem. By August 13, the team confirmed that all **Cosmos EVM** chains were affected, regardless of their decimal configuration. Despite this, the fix was distributed via a public silent patch process, typically reserved for issues not causing fund loss on production chains. ### Deviation from Security Protocols This approach directly contradicted the company's own [published silent patch policy](https://docs.cosmos.network/sdk/latest/security/bug-bounty#silent-patch-and-disclosure-process), which mandates emergency mitigations and private fix distribution for issues posing an immediate or network-wide risk. **Cosmos Labs** justified its decision by stating, “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.” ### Technical Breakdown of the Flaw The vulnerability resides in the code responsible for reconciling the **Ethereum Virtual Machine (EVM)** state with the **Cosmos SDK** `x/bank` module. The **EVM** `StateDB` only tracks an account's spendable balance, while vesting accounts in **SDK** state hold both spendable and locked balances. 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. This unchecked subtraction causes the balance to wrap around to approximately 2^256. Attackers could then move a finite amount from the wrapped account or manipulate victim accounts by sending 2^256 minus their balance, causing reconciliation to burn the victim's real holdings. Chains running `0.6.x` versions experienced supply overflows that halted the chain, while `0.7.x` versions directly set balances in `x/bank`, accepting changes that survived a `uint256` to `int256` conversion. Exploitation required the chain to permit permissionless vesting-account creation and involved a contract deployed to a precomputed address that was first converted into a vesting account. ### Incident Timeline and Impact A public pull request in **Push Chain**'s fork of **Cosmos EVM** detailed the vulnerability and its exploitation path on August 20, just hours after the patched releases went out. The first attack, targeting **MANTRA**, commenced approximately eleven hours later. **Cosmos Labs** sent its first private notification by secure email on August 21, roughly two hours after **MANTRA** reported the exploitation. The attackers successfully sold approximately **USD 2.87 million** in affected assets on decentralized exchanges and an estimated **USD 2.85 million** on centralized exchanges, totaling roughly **USD 5.72 million** in losses. ### Remediation and Operator Guidance **Cosmos Labs** advises operators running **Cosmos EVM** to take the following critical steps: * **Upgrade Immediately:** Transition to v0.6.2 or v0.7.2 or later via a coordinated network upgrade, as the change is state-breaking. * **Halt if Unable to Upgrade:** Chains unable to upgrade immediately should halt block production rather than attempt a coordinated governance upgrade. There is no configuration-only mitigation. * **Close the Precondition:** Reject `MsgCreateVestingAccount`, `MsgCreatePermanentLockedAccount`, and `MsgCreatePeriodicVestingAccount` in the ante handler. Vesting accounts defined in genesis are unaffected. * **Verify Live Code Path:** On a fork, verify that cherry-picked patches fully cover all instances of the affected code, as duplicated unexported copies can remain unpatched. * **Apply Omitted Fixes:** Independently apply the locked-balance snapshot and module-account guard fixes, which were not explicitly mentioned in the advisory. * **Register Security Contact:** Operators should register a security contact with **Cosmos Labs**, as 11 affected deployments were unknown to their security channels during the incident. ### The Wider Ecosystem Challenge This incident highlights a broader challenge within the **Cosmos** ecosystem, which spans over 115 known public blockchains. **Cosmos Labs** acknowledges it lacks a complete registry of networks running its software, a gap that previously hindered rapid patch distribution for other vulnerabilities. **ZetaChain** contributor **morde08** published a [port of all three fixes](https://github.com/zeta-chain/evm/pull/31) on August 21, noting that a cherry-picked patch might leave unexported helper functions unpatched. **Warden Protocol** adopted a more direct approach, blocking 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,” stated **Warden Protocol** contributor **jlehtimaki** in a commit message. This event underscores the complexities of securing decentralized ecosystems and the critical need for robust, transparent, and rapidly executed security protocols, especially when user funds are at stake.