Cosmos Labs misread vulnerability caused a $5.7 million six-chain attack

Key Points

Six Cosmos EVM networks were attacked.

The attacker converted approximately US$5.72 million in assets.

Cosmos Labs underestimated the reported vulnerability.

Operators must upgrade or suspend affected chains.

Cosmos Hub was not compromised.

Cosmos Hub was not attacked

This incident did not affect Cosmos Hub or every blockchain in the entire Cosmos ecosystem. The vulnerability lies in cosmos/evm, a shareware that allows independent Cosms-based networks to run Ethereum-compatible applications. According to a post-mortem analysis by Cosmos Labs, six networks using the software were attacked between August 20 and August 25. MANTRA, TAC and KiiChain are mentioned in the detailed timeline, but the names of the other three networks are not disclosed. This distinction avoids the misleading title of shared software failures being misinterpreted as "Cosmos hacked." The same scoping rules apply to sandbox bridging attacks: a compromised integration point does not mean that the entire underlying protocol has been compromised.

Attacker converted US$5.72 million through two paths

Cosmos Labs estimates that based on August 19 prices, attackers redeemed approximately $2.87 million through decentralized venues. The figure is described as an estimate that is not independently audited. An additional approximately US$2.85 million was reported to be sold through centralized exchanges, bringing the total amount exchanged or sold to approximately US$5.72 million. Cosmos Labs said the affected chain reported that the relevant centralized exchange accounts had been frozen while the police continued to investigate. The total conversion amount of $5.72 million will not change, but recovering frozen exchange balances may reduce the final net loss. This response also limited the scope of damage. Cosmos Labs worked with 13 other potentially exposed networks to patch, suspend or protect them, and no further incidents were reported. A total of 40 chains were coordinated.

How accounting mismatches expose effective balances

This vulnerability stems from the differences in how balances are calculated by two parts of the software. Cosmos EVM's StateDB only tracks the amount that an account can spend immediately. Cosmos's home account can hold both expendable and locked tokens, and the pledge system allows locked tokens to be entrusted. When software subtracts the entire entrusted amount from a small expendable balance, an unchecked arithmetic underflow can result in a result close to 2^256. An attacker can then match the overflow with the overflow during the transfer process. This sequence does not lead to a continued increase in supply, but may zero-out the balance of a high-balance victim account and allow the attacker to obtain the balance originally held by the account. This makes the vulnerability a direct risk of capital theft, rather than just a display error or accounting anomaly.

The warning was issued nearly four months before the attack.

The theft was the end of a longer sequence. Decisive errors occur in the initial evaluation phase, months before anyone takes advantage of the code. Security incident and vulnerability disclosure timeline. Cosmos Labs views production threats as routine maintenance. The original proof of concept used a chain configured to six decimal places. Cosmos Labs tested the 18 decimal configuration and failed to replicate the results, so the known production network is considered safe. This conclusion is wrong: underlying balance mismatch issues can affect all Cosmos EVM chains, regardless of their decimal configuration. Once subsequent reports confirmed the broader scope of impact, Cosmos Labs realized production funds had been exposed. It opted for a silent patching process that aims to put fix code into the hands of operators while not disclosing details that might help attackers. These versions were available about 20 hours before the first known attack occurred, but their release notes did not state the severity and did not inform operators that delaying upgrades could expose user funds. Operators can see that the new version contains security fixes, but the instructions do not explain that unpatched chains are at risk of financial loss. The next morning, the disclosure was made public. A pull request from a downstream branch described the attack path and pointed out the affected version tags about 12 hours before the first attack. This public pull request provides attackers with a clearer path. Cosmos Labs has previously let operators make their own judgments in the absence of emergency warnings.

Cosmos does not know all chains that require warnings

Even a private warning process is only effective if the maintainer knows who to contact. Cosmos Labs said the ecosystem contains more than 115 known public chains, but lacks a complete registry. In response, they learned that 11 Cosmos EVM deployments were not registered in their security channels. Cosmos Labs maintains shared code but is unaware of all the networks on which that code is deployed. This gap makes it difficult to issue confidential warnings before releasing enough information for chain teams to identify threats themselves. The response timeline also suggests that the information must be clear and unambiguous. After MANTRA reported the first attack, Cosmos Labs took about two hours to send out the first critical security email. Despite previous communications, TAC was attacked about 45 hours after MANTRA, and the guidelines were subsequently upgraded to recommend that all Cosmos EVM chains be suspended. For a stand-alone Cosmos EVM chain, publishing code is not enough. Their teams still need to recognize the urgency of upgrades and coordinate the release of status changes.

Vulnerable chains must be upgraded or suspended

Critical security bulletins list versions before 0.6.2 and versions between 0.7.0 and 0.7.2 (excluding) as affected. Operators should upgrade to Cosmos EVM version 0.6.2, 0.7.2 or later. There are no workarounds that can be solved through configuration alone. Disabling pledge pre-compilation removes the main trigger conditions described in the announcement, but Cosmos Labs does not believe this step is a substitute for upgrades. Chains for which a patch version cannot be installed immediately should be suspended. BTCPay recently issued similar version-specific instructions after confirming that funds were stolen: update affected installations or take them offline. In both cases, useful guidance is specific because the risks depend on the software version used.

The next fix point is the disclosure process

Cosmos Labs said it will expand its vulnerability assessment beyond proof-of-concept for reporters, expand its secure contact network and check whether those contacts remain responsive. It also plans to develop clearer criteria for private and silent patches, including when maintainers should recommend a pause rather than coordinating upgrades. In addition, an external audit of its operational security practices is planned. These changes address the part of this incident that the code patch cannot resolve: how a decentralized group of independent chains receives, understands, and takes action to respond to time-sensitive security warnings. The initial assessment narrowed the scope of the vulnerability too hastily. The subsequent release process concealed the urgency from some of those expected to install the fix. The code was available before the first attack. But what some operators lack is a clear warning that waiting may mean loss of user funds.