Attackers exploited a critical vulnerability in shared Cosmos software to steal assets across six blockchains over five days, exposing a breakdown in vulnerability assessment and disclosure that allowed a bug reported months earlier to reach live exploitation.
Cosmos Labs said the attacks ran from Aug. 20 through Aug. 25 and targeted Cosmos EVM, an open-source Cosmos SDK module that allows independent blockchains to run Ethereum-compatible smart contracts and tooling. Attackers ultimately converted roughly $2.87 million of stolen tokens through decentralized exchanges and another estimated $2.85 million through centralized exchanges, putting the realized value of the attacks at about $5.7 million.
The centralized exchange accounts used by the attackers have since been frozen pending investigations by relevant authorities, according to Cosmos Labs. No recovered funds had been announced in the post-mortem.
The most significant disclosure, however, concerns when Cosmos Labs first learned about the underlying vulnerability.
A security researcher reported the flaw through the Cosmos bug bounty program on April 25. Cosmos Labs tested it against configurations used by known production networks but concluded it could not be exploited to steal funds from live chains.
Based on that assessment, developers merged an underflow guard into the main Cosmos EVM development branch on May 15 using what Cosmos describes as its “silent patch” process. The company said it had used that approach for dozens of vulnerabilities where it did not believe production funds were at risk.
That conclusion proved wrong.
Additional reports from independent researchers between May and early August eventually allowed Cosmos Labs to reproduce the vulnerability more broadly. The team determined that all Cosmos EVM chains were potentially affected regardless of their decimal configuration.
Rather than privately distributing the fix at that point, Cosmos Labs decided to obfuscate and backport the already-public patch into supported releases. Versions 0.6.2 and 0.7.2 were published at approximately 11:01 p.m. UTC on Aug. 19, with release notes referring to security fixes but without describing the vulnerability or the risk to funds.
The first known attack against MANTRA began at 7:06 p.m. UTC on Aug. 20 — roughly 20 hours later.
MANTRA Lost $3.6 Million
MANTRA was the largest publicly identified victim.
The attacker moved 720.9 million MANTRA tokens, worth approximately $3.6 million at the pre-incident price, from two addresses that had not authorized the transfers. About 600 million tokens came from MANTRA’s burn address, while roughly 120.9 million came from a dormant genesis-era multisignature wallet associated with an earlier incentive program.
MANTRA stressed that no validator keys, administrator keys, governance controls or multisig signers were compromised. The attack instead exploited an unsigned-integer underflow inside the Cosmos EVM balance-accounting system.
Cosmos EVM has to reconcile Ethereum-style account balances with the Cosmos SDK’s native bank and staking modules. Under the vulnerable logic, an account containing locked tokens could delegate more than the balance that the EVM considered spendable. Instead of rejecting the subtraction when the amount dropped below zero, the unsigned integer wrapped around to a number close to 2²⁵⁶.
The critical advisory published Aug. 28 says affected versions include Cosmos EVM releases before 0.6.2 and versions from 0.7.0 through 0.7.1. Operators are instructed to upgrade to 0.6.2, 0.7.2 or later. Cosmos Labs says there is no configuration-only workaround and recommends halting a chain if it cannot immediately perform the required state-breaking upgrade.
MANTRA halted its chain 14 minutes after the second unauthorized transaction and resumed roughly 30 hours later using patched software without rolling back the blockchain.
The episode nevertheless increased MANTRA’s circulating supply because assets previously treated as immovable — particularly tokens in the burn address — became transferable.
MANTRA also criticized how little time downstream operators had to react. Its post-mortem said a state-breaking upgrade across 38 independent validators could not realistically be assessed, built, tested and coordinated in a 20-hour window, particularly without a vulnerability-specific warning.
TAC and KiiChain Were Hit Next
The attacker did not stop with MANTRA.
On Aug. 22, TAC was exploited using the same vulnerability chain. Nearly 3 billion TAC were removed from its staking pool, according to Cosmos Labs, with approximately 1.2 billion tokens eventually sold on BNB Chain for about $950,000.
KiiChain was attacked later the same day. Approximately 148.3 million KII were extracted through 18 exploit iterations. Cosmos Labs said about 67.6 million KII were bridged to BNB Chain, where 64.6 million were exchanged for roughly $1.61 million in USDT. Around 80.7 million KII — approximately 54% of the amount removed — remained on KiiChain and could potentially be recovered if the network is restored.
Three additional networks were also attacked before the campaign ended on Aug. 25, although Cosmos Labs did not identify them in its post-mortem.
Nesa appears to be another possible victim. Bitvavo suspended NES deposits and withdrawals on Aug. 24 after what the exchange described as a “critical consensus vulnerability” caused vulnerable nodes to accept invalid blocks. Cosmos Labs has not publicly confirmed Nesa as one of the six affected chains.
One further complication emerged shortly before the first MANTRA attack.
At 7:16 a.m. UTC on Aug. 20, a developer working on Push Chain published a pull request that described the vulnerability and its exploitation path, crediting an independent Hacken audit. That disclosure appeared about 11 hours and 50 minutes before the first known exploit. Cosmos Labs described publishing an exact exploit path publicly before coordinated remediation as highly unusual and said it could increase the likelihood of an attack.
Cosmos Labs ultimately coordinated with 40 chains during the response and said it helped additional networks patch or halt before attackers could reach them.
The company has now promised changes to how it assesses vulnerabilities, communicates security-critical information and maintains contact with operators using Cosmos software.
Analysis: The $5.7 Million Loss Exposed a Coordination Problem Bigger Than the Bug
The most damaging part of the Cosmos incident is not that developers made a programming mistake. Complex blockchain infrastructure will inevitably contain bugs.
The harder problem is that the system discovered this one, fixed it and still failed to prevent the attack.
A researcher reported the vulnerability almost four months before funds were stolen. The code-level fix existed from May. By early August, Cosmos Labs understood that its original assessment was wrong and that production networks were vulnerable.
At that point, the security problem became a coordination problem.
Cosmos EVM is shared infrastructure, but the chains running it are independent. Each has its own validators, governance processes, release schedules and engineering teams. Cosmos documentation specifically emphasizes that EVM-based Cosmos chains retain control of their own validator sets and governance. That sovereignty is one of the architecture’s selling points.
During an emergency, it can also become a weakness.
An ordinary centralized software company can deploy a security update across its own servers. Cosmos Labs cannot simply install a state-breaking patch on dozens of sovereign blockchains. Validators need to obtain the release, inspect it, coordinate an upgrade and agree when to change software.
That means the warning accompanying a patch can be almost as important as the patch itself.
Telling an operator that a release includes “important security fixes” is very different from telling it that an attacker may be able to move assets without authorization and that the network should halt if an immediate upgrade is impossible.
MANTRA’s criticism lands particularly hard here because the chain was not disputing whether Cosmos developers eventually fixed the bug correctly. It was arguing that the information needed to prioritize that fix arrived too late.
The public Push Chain disclosure further compressed the timeline, but it does not erase the earlier issue. By the time the exploit path became public on Aug. 20, Cosmos Labs had already known for weeks that the vulnerability affected production networks.
There is also an uncomfortable security trade-off behind silent patches.
Keeping the details of a vulnerability secret can prevent attackers from reverse-engineering it while operators update. But once the corrective code itself is publicly available, secrecy becomes fragile. Skilled attackers can compare releases, examine changed arithmetic or validation logic and work backward toward the bug.
That is especially dangerous when an ecosystem has no complete list of who is running the affected software. Cosmos Labs said the response uncovered 11 Cosmos EVM deployments it had not previously registered. In an open-source ecosystem, software can spread farther than its maintainers’ security contact list.
The result is a structural lesson for modular blockchain ecosystems.
Shared code allows dozens of networks to inherit improvements without rebuilding everything from scratch. It also allows one mistake to become a common point of failure. The more successful a shared module becomes, the larger the potential blast radius of a vulnerability inside it.
Cosmos Labs has acknowledged that its processes need to change. Better vulnerability triage, stronger private notification channels and clearer standards around when operators should halt are sensible responses.
But the incident shows that responsible disclosure in decentralized infrastructure cannot end with fixing code. Maintainers also need to know who depends on that code, how quickly those operators can upgrade and what happens when a vulnerability is too dangerous to leave a network running.
The $5.7 million may ultimately be the measurable loss from this episode. The more important failure was the nearly four-month gap between discovering the weakness and protecting every chain that was relying on it.
