31 AUG 2026 — A balance-handling flaw in the shared Cosmos EVM module was used to drain about US$5.72m from six blockchains between 20 and 25 August, halting three of them. The fix shipped on 19 August. The exploitation began the next day.

The sequence

Cosmos Labs received the report through its bug bounty programme on 25 April and assessed it at the time as posing no risk to funds on live networks. Patched versions 0.6.2 and 0.7.2 shipped on 19 August, published as a GitHub security advisory. Draining started on 20 August and ran to 25 August. A post-mortem followed on 28 August.

About US$2.87m moved through decentralised exchanges and another US$2.85m through centralised ones. Cosmos Labs says it contacted 40 networks.

25 AprilReported, and assessed as no risk to live funds
19 → 20 AugFix published, then exploitation began
$5.72mDrained across six chains, three halted
No CVENo CVE, no CWE class, no CVSS score

The advisory is the disclosure

A security advisory that ships alongside a patch necessarily describes what was wrong. For open-source software the patch itself is a public diff, and the diff is a map.

The one-day gap between publication and exploitation was not a coincidence or evidence of a leak. It was the normal consequence of fixing a bug in public. We reported that most exploitation now lands within 48 hours of a proof of concept, and this is that finding with money attached.

There is no better option available. Silent patching leaves operators unable to judge urgency and does not stop anyone who reads commit logs. Coordinated disclosure with an embargo works when the affected parties are a known list, and here the affected parties are every chain running a shared module, which is why 40 networks had to be contacted rather than notified through one channel.

So the honest framing is that publishing the fix started a race, and the chains that lost it were the ones that had not upgraded within a day.

Four months of believing it was harmless

The April assessment was the failure that made everything after it possible.

A researcher reported the flaw and the maintainers concluded it posed no risk to funds on live networks. They were wrong, and the interesting question is what kind of wrong. Balance-handling bugs are frequently reachable only under conditions that do not obviously exist — a particular module combination, a specific transaction ordering, a configuration most chains do not run. An assessment of no risk on live networks is usually a judgment that no active chain has the vulnerable configuration — a claim about deployment, not about the code itself.

That judgment is exactly the kind that decays. Chains change configuration, add modules and upgrade dependencies, and nobody re-runs a triage decision from four months ago when they do. A severity assessment has a shelf life and is almost never re-examined.

A missing CVE is not a formality

The advisory was published as GHSA-7g4w-cg88-2cq2, with no CVE identifier, no weakness classification and no CVSS score.

Those absences have practical consequences rather than bureaucratic ones. Vulnerability scanners, software composition analysis tools and dependency alerting are largely keyed on CVE identifiers, so an advisory without one is invisible to a substantial part of the tooling that operators rely on to be told they are affected. A GitHub advisory reaches those watching that specific repository; a CVE reaches everyone whose scanner runs nightly.

The absence of a CVSS score compounds it. Operators triage by score because they have more advisories than time, and an advisory carrying the word critical in prose but no number does not sort into anyone's queue. Cosmos Labs rated it critical; nothing automated could read that.

Shared modules concentrate risk the way shared libraries do

One bug reached six chains because they all run the same module, and that generalises well beyond cryptocurrency.

Blockchains are usually discussed as independent systems whose separation is the point. In practice a large number of them are assembled from the same small set of frameworks, and a flaw in a shared component is a flaw in every chain that imported it. That is ordinary software supply-chain risk wearing unfamiliar clothes, and it is not mitigated by anything distinctive about distributed ledgers.

The three halted chains illustrate the other half of it. Halting is the correct emergency response and it is only available because these networks have a small enough validator set to coordinate a stop, which is the property their designs are usually defended against having.

What an operator should take from it

There are three takeaways here, and the first is the one most likely to be skipped.

Watch the advisory feed for every framework you import, not only the CVE feed, because this advisory would never have appeared in the latter. For a chain or any project built on a shared framework, the upstream repository's security tab is a primary source and needs someone assigned to it.

Treat a shipped fix as the start of the exposure window rather than the end. The day a patch is published is the day the vulnerability becomes widely known, and an upgrade window measured in weeks is a decision to be exploited.

Revisit triage decisions when configuration changes. A four-month-old judgment that a flaw is unreachable was based on a deployment picture that no longer exists.