The Cosmos Hub was not hacked

The incident did not compromise the Cosmos Hub, nor every blockchain in the wider Cosmos ecosystem. The flaw sat in cosmos/evm, shared software that allows independent Cosmos-based networks to run Ethereum-compatible applications.

According to the Cosmos Labs post-mortem, six networks using that software were exploited between August 20 and August 25. MANTRA, TAC and KiiChain were named in the detailed timeline; the document did not identify the other three publicly.

That distinction matters: it prevents a shared-software failure from becoming a misleading "Cosmos hack" headline. The same scope rule applied to The Sandbox bridge exploit — a compromised integration did not mean the entire underlying protocol had been hacked.

Attackers converted $5.72M through two routes

Cosmos Labs estimated that attackers exchanged roughly $2.87 million through decentralized venues, based on August 19 prices. It described that figure as an estimate that had not been independently audited. A further $2.85 million was reportedly sold through centralized exchanges, bringing the total converted or sold to about $5.72 million.

Cosmos Labs said the affected chains reported that the centralized-exchange accounts had been frozen while police investigations continued. The $5.72 million conversion total will not change, but recovery of frozen exchange balances could reduce the final net loss.

The response also limited the damage. Cosmos Labs worked with 13 other potentially exposed networks to patch, halt or otherwise protect them without further reported incidents, and coordinated with 40 chains overall.

How an accounting mismatch exposed valid balances

The vulnerability originated in two parts of the software calculating balances differently. Cosmos EVM's StateDB tracked only the amount an account could spend immediately. A Cosmos vesting account, however, could hold both spendable and locked tokens, and the staking system allowed locked tokens to be delegated.

When the software subtracted the full delegated amount from the smaller spendable balance, an unchecked arithmetic underflow could wrap the result to a number close to 2^256. An attacker could then pair that underflow with an overflow during a transfer. This class of bug — integer underflow and overflow in unsigned arithmetic — is a well-documented category of smart-contract and blockchain vulnerability, and it is one reason modern smart-contract languages include checked arithmetic by default.

The sequence did not create a lasting increase in supply. Instead, it could reduce a high-balance victim account to zero and leave the attacker with the balance previously held by that account. That made the flaw a direct fund-theft risk, not merely an inaccurate display or accounting oddity.

The warning arrived nearly four months before the attacks

The theft was the end of a longer sequence. The decisive mistake came during the initial assessment, months before anyone exploited the code.

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 18-decimal configurations, could not reproduce the result, and concluded that known production networks were safe. That conclusion was wrong: the underlying balance mismatch could affect every Cosmos EVM chain, regardless of its decimal configuration.

Once later reports established the wider reach, Cosmos Labs knew that production funds were exposed. It chose a silent-patching process intended to put fixed code in operators' hands without publishing details that could help attackers.

The releases were available about 20 hours before the first known attack, but their notes did not state the severity or tell operators that delaying the upgrade could expose user funds. Operators could see that new releases contained security fixes, but the notes did not explain that unpatched chains faced potential fund loss.

The disclosure became public the following morning. A pull request in a downstream fork described the exploit path and identified affected release tags roughly 12 hours before the first attack. The public pull request gave attackers a clearer path, and Cosmos Labs had already left operators without a warning that explained the urgency.

The dilemma Cosmos Labs faced is familiar in open-source security: fully disclosing a vulnerability can arm attackers before every operator has patched, while staying silent can leave operators unable to judge urgency. Coordinated-disclosure practices across the software industry try to balance exactly this trade-off, and this incident shows what happens when the balance tips wrong on both sides.

Cosmos did not know every chain that needed warning

Even a private warning process works only if maintainers know whom to contact. Cosmos Labs said the ecosystem includes more than 115 known public chains but lacks a complete registry. During the response, it learned of 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 difficult to deliver a confidential warning before publishing enough information for chain teams to recognize the threat themselves.

The response timeline also shows why the message had to be explicit. After MANTRA reported the first attack, Cosmos Labs sent its first critical secure email about two hours later. TAC was attacked roughly 45 hours after MANTRA despite earlier communication, and the guidance later escalated to advising all Cosmos EVM chains to halt.

For independent Cosmos EVM chains, publishing the code was insufficient. Their teams still had to learn that the upgrade was urgent and coordinate a state-breaking release.

Vulnerable chains must upgrade or halt

The critical security advisory lists versions before 0.6.2 and versions from 0.7.0 up to, but not including, 0.7.2 as affected. Operators should move 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 treat that step as a substitute for upgrading. A chain that cannot install a patched release immediately should halt.

BTCPay recently issued similarly version-specific instructions after confirming stolen funds: update affected installations or take them offline. In both cases, the useful guidance is concrete 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 security contact network, and check whether those contacts remain responsive. It also plans clearer standards for private and silent patches, including when maintainers should recommend a halt instead of a coordinated upgrade. An external audit of its operational security practices is also planned.

Those 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 first assessment narrowed the bug too quickly. The later release process concealed the urgency from some of the people expected to install the fix. The code was available before the first attack. What several operators lacked was a warning that waiting could cost user funds.

The 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.

Source: Coindoo