A critical vulnerability in the shared Cosmos EVM module, designated GHSA-7g4w-cg88-2cq2, was actively exploited between August 20-25, 2026, resulting in fund drainage from six blockchains. Cosmos Labs confirmed awareness of the flaw prior to exploitation. The vulnerability involves a balance-handling flaw affecting versions below 0.6.2 and certain versions above. No CVE identifier, weakness classification, or CVSS score was assigned despite the critical rating. The incident highlights risks associated with shared modules across multiple blockchain ecosystems, where a single flaw can have cascading effects on numerous platforms.
The vulnerability (GHSA-7g4w-cg88-2cq2) is a critical balance-handling flaw in the shared Cosmos EVM module. It exists at the interface between the Ethereum Virtual Machine (EVM) StateDB and the Cosmos SDK x/bank module. The EVM StateDB tracks only an account's spendable balance, while vesting accounts in SDK state hold both a spendable and a locked balance. Both 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 figure. This subtraction is unchecked, causing the balance to wrap around to approximately 2^256 (integer underflow). Reconciliation then mints on a positive delta and burns on a negative one, allowing an attacker to move funds out of the wrapped account or send a victim account 2^256 minus its balance, causing reconciliation to burn the victim's real holdings. On chains running v0.6.x, a large mint causes a supply overflow that halts the chain. On v0.7.x chains, balances are set directly in x/bank and accept changes that survive a uint256 to int256 conversion. Both attack halves run inside a single transaction with a net supply change of zero, from a contract deployed onto a precomputed address that was first turned into a vesting account. Exploitation requires the chain to permit permissionless vesting-account creation. The vulnerability was first reported via bug bounty on April 25, 2026. Cosmos Labs initially assessed it as affecting only non-18-decimal networks. By August 13, 2026, all Cosmos EVM chains were confirmed affected regardless of decimal configuration. Patches were released on August 19 (v0.6.2 and v0.7.2), but exploitation details were publicly exposed in a pull request at 07:16 UTC on August 20. The first attack against MANTRA began at 19:06 UTC on August 20. A cherry-pick patching only the exported helper can leave a duplicated unexported copy unpatched while all tests still pass. Three upstream fixes are relevant: PR #1176 (SubBalance underflow guard), PR #1187 (locked-balance snapshot fix), and commit 3524ebc (module-account guard). The advisory only documents PR #1176; the other two fixes are omitted. Approximately USD 2.87 million was sold on decentralized exchanges and USD 2.85 million on centralized exchanges.
1. Upgrade to Cosmos EVM v0.6.2 or v0.7.2 or later as a coordinated network upgrade, as the change is state-breaking. 2. Halt chain rather than vote: chains that cannot upgrade immediately should stop block production instead of running a coordinated governance upgrade. There is no configuration-only mitigation. 3. Close the precondition by rejecting MsgCreateVestingAccount, MsgCreatePermanentLockedAccount, and MsgCreatePeriodicVestingAccount in the ante handler. Vesting accounts defined in genesis are unaffected. 4. Disabling the staking precompile removes the primary trigger path but is not a substitute for the patch. 5. Verify the live code path on a fork: a cherry-pick that patches only the exported helper can leave a duplicated unexported copy in place while every test still passes. 6. Apply all three fixes: the SubBalance underflow guard (PR #1176), the locked-balance snapshot fix (PR #1187), and the module-account guard (commit 3524ebc). Note that the module-account guard rejects module accounts unconditionally, which may break EVM calls made from a module account. 7. Register a security contact with Cosmos Labs to receive private vulnerability notifications. 8. Chain operators should audit their deployment to ensure they are running patched versions and have not applied only partial cherry-picks.
