Six Cosmos Chains Hit in a $5.72M Exploit—But Here’s Why It’s Not a ‘Cosmos Hack’
Shared Code, Not the Cosmos Hub: Understanding the Scope of the Attacks
In late August, six blockchain networks tied to the Cosmos ecosystem found themselves at the center of a serious security incident, one that saw roughly $5.72 million in digital assets converted or sold by attackers. But the first thing Cosmos Labs wants everyone to understand is that this was not a breach of the Cosmos Hub, nor was it a blanket compromise of every blockchain built on Cosmos technology. According to the post-mortem published by Cosmos Labs, the vulnerability responsible for the thefts sat inside cosmos/evm, a shared piece of software that allows independent Cosmos-based networks to run Ethereum-compatible applications. The affected chains were exploited between August 20 and August 25, with MANTRA, TAC and KiiChain explicitly named in the detailed timeline. The other three networks were not publicly identified in the document. That distinction matters, and not just for the sake of accurate headlines. A flaw in shared infrastructure is fundamentally different from a direct attack on a core network, and conflating the two can distort how the broader crypto community assesses risk. The same confusion surfaced during The Sandbox bridge exploit, when a compromised integration was mistakenly characterized by some as a hack of the underlying protocol itself. Here, as there, the core chain remained intact, but a vulnerable point in widely reused code was enough to cause real, measurable damage across multiple independent projects. Cosmos Labs estimated that attackers exchanged roughly $2.87 million through decentralized venues, based on August 19 prices. That figure, it stressed, had not been independently audited. Another $2.85 million was reportedly sold through centralized exchanges, bringing the total converted or sold to about $5.72 million. The headline number is certainly attention-grabbing, but the more important story lies in how the attackers pulled it off—and why the warning signs were visible months before anyone acted on them.
The Accounting Mismatch That Made the Exploit Possible
To understand how the attack worked, it helps to understand a subtle accounting flaw inside Cosmos EVM’s balance-tracking system. The problem began when two different parts of the software computed balances differently. Cosmos EVM’s StateDB, the module’s internal ledger, recorded only the amount an account could spend immediately. A Cosmos vesting account, though, could hold both spendable and locked tokens, and the staking system allowed those locked tokens to be delegated to validators. In many ways, this was by design: locking tokens for vesting did not necessarily remove them from staking participation. The trouble came when the software tried to subtract a delegated amount from an account’s spendable balance. If the delegated sum exceeded that spendable balance, the arithmetic did not fail gracefully. Instead, an unchecked underflow could occur, wrapping the result to a number close to2^256—the mathematical ceiling of the Ethereum Virtual Machine’s 256-bit arithmetic. An attacker could then combine that underflow with a carefully crafted overflow during a subsequent transfer, effectively turning the distorted balance calculation into a theft mechanism. The end result was not a temporary accounting glitch or a cosmetic display error. It was a direct transfer of value: a high-balance victim account could be reduced to zero, with the attacker walking away holding the balance that had previously belonged to that account. Perhaps just as important, this exploit did not create new tokens out of thin air or permanently inflate the total supply. It redistributed existing funds by abusing a flaw in how the software reconciled balances. That distinction matters because it separates this attack from a simple minting bug. This was a pure fund-theft vulnerability, the kind that keeps developers awake at night, precisely because it doesn’t announce itself as a supply anomaly; it just quietly moves money to someone who shouldn’t have it.
A Warning Four Months Before the Theft—and Why It Wasn’t Heeded
The most uncomfortable part of this story is not the exploit itself, but how long the warning sat unheeded before it became an attack. According to the post-mortem, the decisive mistake occurred months before anyone actually stole funds, during the initial assessment of a proof-of-concept that had been submitted by a security researcher. That original proof of concept used a chain configured with six decimal places, and Cosmos Labs found itself unable to reproduce the result when testing configurations with eighteen decimal places—the standard for many production networks. On that basis, Cosmos Labs concluded that known production chains were safe. That conclusion turned out to be wrong, and not in a marginal way. The underlying balance mismatch was not a decimal-place quirk; it could affect every Cosmos EVM chain, regardless of how many decimal places its token used. The team’s initial triage had effectively narrowed the bug too quickly, treating what looked like an edge case as evidence that production deployments were immune. By the time later reports established the broader reach of the vulnerability, production funds were no longer a theoretical concern. They were exposed. The warning had arrived nearly four months before attacks began, but it had been filed away under a mistaken assumption. That kind of false reassurance is especially dangerous in decentralized ecosystems, where one shared vulnerability can ripple across dozens of independent networks whose security depends on the same underlying code. The lesson, as Cosmos Labs itself acknowledged, was that a proof of concept designed around one configuration cannot be dismissed simply because it doesn’t reproduce ander another configuration; it must be understood at the level of the underlying logic.
A Silent Patch, a Public Pull Request, and a Race Against Time
By the time Cosmos Labs understood the true scope of the flaw, it found itself in a deeply uncomfortable position. Publicly disclosing the vulnerability could invite copycat attacks, but staying silent meant operators of vulnerable chains would have no reason to upgrade urgently. Cosmos Labs chose a silent patching strategy: it would place fixed code in the hands of operators without publishing the kind of technical detail that could help an attacker exploit the flaw before patches were widely applied. The patched releases were available approximately twenty hours before the first known attack occurred. But there was a catch. The release notes did not explicitly state the severity of the vulnerability, nor did they tell operators that delaying the upgrade could expose user funds. A sharp-eyed developer could see that security fixes were included, but nothing in the notes conveyed the urgency. The very next morning, details became public through another route. A pull request in a downstream fork described the exploit path and identified affected release tags roughly twelve hours before the first attack. That public pull request effectively handed attackers a clearer roadmap to the vulnerability. Meanwhile, Cosmos Labs was already trying to corral an ecosystem that was not built for rapid, confidential coordination. After MANTRA reported the first attack, Cosmos Labs sent its first critical secure email about two hours later. But TAC was attacked roughly forty-five hours after MANTRA, despite earlier communication having taken place. Eventually, the guidance escalated, urging all Cosmos EVM chains to halt if they could not confirm their status. For independent Cosmos EVM chains, simply publishing the fixed code was never going to be enough. Their teams still had to learn that the upgrade was urgent, assess whether their particular deployment was affected, and coordinate a release that might require a state-altering change. Cosmos Labs said it coordinated with 40 chains overall and worked directly with 13 other potentially exposed networks to patch, halt, or otherwise protect them without further reported incidents. The response did limit the overall damage, but not before six networks had already been drained. What makes that especially frustrating is that the code was available before the first attack. What operators lacked, in several cases, was a warning clear enough to make them understand that waiting could cost user funds.
The Unseen Vulnerable: When You Don’t Know Who’s Running Your Code
Even a perfectly executed private warning process depends on one basic premise: that maintainers know whom to contact. Cosmos Labs, by its own account, could not meet that premise. The Cosmos ecosystem is vast, encompassing more than one hundred fifteen known public chains, and yet it lacks a complete registry of every network that has deployed Cosmos EVM. During the response, Cosmos Labs learned of eleven Cosmos EVM deployments that had never been registered in its security channels. That gap is not an administrative triviality. It goes to the heart of why a warning delivered to some operators did not reach everyone who needed it. Cosmos Labs maintained the shared code without having a complete picture of every network running it, and that made it nearly impossible to deliver a confidential warning before publishing enough information for chain teams to recognize the threat on their own. For operators, however, the path forward is unambiguous. The critical security advisory lists versions before 0.6.2, as well as versions from0.7.0 up to but not including0.7.2, as affected. Any chain running one of those versions 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 as a substitute for upgrading. If a chain cannot install a patched release immediately, the guidance is clear: halt. That kind of version-specific, action-oriented guidance is exactly what was missing earlier. It also mirrors what BTCPay recently did after confirming stolen funds, issuing similarly concrete instructions: update affected installations or take them offline. In both cases, rushing to a binary admonition to “update” is less useful than clearly stating which versions are vulnerable and which are safe. The risk depends on the software version in use, andthe response must reflect that specificity.
Recovery, Reforms, and the Harder Fix: Rethinking Security Disclosure
The financial aftermath of the exploit is still unfolding, and there is a realistic chance that the final loss will be smaller than the initial headline number. Cosmos Labs said affected chains reported that centralized-exchange accounts connected to the attackers had been frozen while police investigations continued. The $5.72 million conversion total is unlikely to change, because that figure reflects assets already converted or sold. But if some of those frozen exchange balances are successfully recovered, the net loss could be reduced. In other words, law enforcement and exchanges may still claw back a meaningful slice of what was taken. For Cosmos Labs, though, the longer-term project is not just about recovering funds; it’s about making sure the same failure of communication doesn’t happen again. The post-mortem laid out a series of reforms aimed at exactly that. Cosmos Labs said it will broaden vulnerability triage beyond the original reporter’s proof of concept, meaning future reports will be examined for their underlying logic rather than dismissed because one configuration didn’t reproduce the issue. It also plans to expand its security contact network, and to proactively check whether those contacts remain responsive, rather than assuming a channel from last year is still monitored. The team intends to establish clearer standards for private and silent patches, including explicit guidance on when maintainers should recommend a halt instead of a coordinated upgrade. And an external audit of its operational security practices is also planned. These changes are aimed at the part of the incident that no code patch can 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 very people expected to install the fix. The code was available before the first attack, finally. What several operators lacked was a warning that waiting could cost user funds. That may be the most expensive bug of all—and the one Cosmos is now trying to fix.
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.
