The Cosmos Hub was not hacked. The incident affected shared software used by some independent Cosmos-based networks, not the Cosmos Hub or every blockchain in the wider Cosmos ecosystem.
The vulnerability was found in cosmos/evm, which enables Cosmos-based networks to run Ethereum-compatible applications. According to the Cosmos Labs post-mortem, six networks using the software were exploited between August 20 and August 25. MANTRA, TAC and KiiChain were identified in the detailed timeline, while the other three networks were not publicly named.
That distinction is important: a failure in shared software does not mean the entire Cosmos ecosystem suffered a “Cosmos hack.” The same principle applied to The Sandbox bridge exploit, where a compromised integration did not mean the underlying protocol had been hacked.
Attackers converted approximately $5.72 million
Cosmos Labs estimated that attackers exchanged approximately $2.87 million through decentralized venues, using prices from August 19. The company said the figure was an estimate that had not been independently audited. Attackers reportedly sold another $2.85 million through centralized exchanges, bringing the total amount converted or sold to roughly $5.72 million.
Cosmos Labs said affected chains reported that the centralized-exchange accounts had been frozen while police investigations continued. The $5.72 million conversion total will not change, although recovery of frozen exchange balances could lower the eventual net loss.
The response also helped limit the damage. Cosmos Labs worked with 13 other potentially exposed networks to patch, halt or otherwise protect them, with no further reported incidents. The company coordinated with 40 chains overall.
How an accounting mismatch exposed valid balances
The vulnerability resulted from two parts of the software calculating account balances differently. Cosmos EVM’s StateDB tracked only the amount an account could spend immediately. Cosmos vesting accounts, however, could contain both spendable and locked tokens, while the staking system allowed locked tokens to be delegated.
When the software subtracted the full delegated amount from the smaller spendable balance, unchecked arithmetic underflow could wrap the result to a number close to 2256. An attacker could then combine that underflow with an overflow during a transfer.
The exploit did not create a lasting increase in the total token supply. Instead, it could reduce a high-balance victim account to zero and give the attacker the balance previously held by that account. The flaw therefore created a direct fund-theft risk rather than merely causing an inaccurate display or accounting discrepancy.
The warning came nearly four months before the attacks
The theft followed a longer sequence of events, with the decisive error occurring during the initial security assessment months before the code was exploited.
Timeline of the security incident and exploit disclosures.
Cosmos Labs treated a production threat as routine maintenance
The original proof of concept used a chain configured with six decimal places. Cosmos Labs tested configurations using 18 decimals, failed to reproduce the issue and concluded that known production networks were safe. That conclusion was incorrect: the underlying balance mismatch could affect every Cosmos EVM chain, regardless of its decimal configuration.
After later reports established the vulnerability’s broader reach, Cosmos Labs knew that production funds were exposed. It chose a silent-patching process designed to place fixed code in operators’ hands without publishing details that could help attackers.
The releases were available approximately 20 hours before the first known attack. However, the release notes did not state the severity of the issue or tell operators that delaying the upgrade could expose user funds. Operators could see that the releases included security fixes, but the notes did not explain that unpatched chains faced potential losses.
The disclosure became public the following morning. A pull request in a downstream fork described the exploit path and identified affected release tags approximately 12 hours before the first attack, giving attackers a clearer route. By then, Cosmos Labs had already failed to provide operators with a warning explaining the urgency.
Cosmos Labs did not know every chain that needed a warning
A private warning process works only when maintainers know whom to contact. Cosmos Labs said the ecosystem includes more than 115 known public chains but does not have a complete registry. During the response, it discovered 11 Cosmos EVM deployments that were not registered in its security channels.
Cosmos Labs maintained the shared code without knowing every network that had deployed it. That gap made it harder to deliver a confidential warning before enough information was public for chain teams to identify the threat themselves.
The response timeline also showed why the warning needed to be explicit. After MANTRA reported the first attack, Cosmos Labs sent its first critical secure email approximately two hours later. TAC was attacked roughly 45 hours after MANTRA despite earlier communication. Guidance later escalated to advise all Cosmos EVM chains to halt.
For independent Cosmos EVM chains, publishing the code was not enough. Their teams also needed to understand that the upgrade was urgent and coordinate a state-breaking release.
Vulnerable chains must upgrade or halt
The critical security advisory identifies versions before 0.6.2 and versions from 0.7.0 up to, but not including, 0.7.2 as affected. Operators should upgrade to Cosmos EVM 0.6.2, 0.7.2 or a later release.
There is no configuration-only workaround. Disabling the staking precompile removes the primary trigger described in the advisory, but Cosmos Labs does not consider that a substitute for upgrading. A chain that cannot immediately install a patched release should halt.
BTCPay recently issued similarly specific instructions after confirming stolen funds: update affected installations or take them offline. In both cases, the guidance is useful because the risk depends on the software version in use.
The next fix is the disclosure process
Cosmos Labs said it will broaden vulnerability triage beyond the reporter’s proof of concept, expand its network of security contacts and verify that those contacts remain responsive. It also plans to establish clearer standards for private and silent patches, including when maintainers should recommend a halt rather than a coordinated upgrade.
An external audit of its operational security practices is also planned. These changes address the part of the incident that another code patch cannot solve: how a decentralized group of independent chains receives, understands and acts on a time-sensitive warning.
The initial assessment narrowed the vulnerability too quickly. The later release process concealed its urgency from some of the people expected to install the fix. The code was available before the first attack, but several operators lacked a warning that made clear that waiting could cost users their funds.
This article is for informational purposes only and does not constitute financial, investment or security advice. Network operators should consult the official Cosmos EVM advisory and verify their deployed version.
