Severity Daily

IT and AI security incidents, checked against the primary source

Tag: Cosmos EVM

  • PaperCut needed a second emergency patch, and the record spent the day contradicting its own authors

    PaperCut needed a second emergency patch, and the record spent the day contradicting its own authors

    The most consequential item on the site today is that PaperCut’s zero-day now needs a second emergency patch, because researchers bypassed the first one. Anyone who patched on August 27 is not protected. The flaw now has two numbers — CVE-2026-81578, an unauthenticated access-control bypass in the web management interface, and CVE-2026-82078, unsafe dynamic class loading — and they chain. Huntress has found evidence of exploitation in two customer environments. That outranks the bigger-sounding story of the day. Manchester Airports Group confirmed that roughly 8.7 million customers’ details were taken from a third-party-hosted database, and the number is real, but nobody reading this can act on it tonight. An internet-facing print server running a build that a public bypass defeats is a task, not a headline.

    The day had a thread, and it is a sharper version of yesterday’s: the record did not merely lag the risk, it contradicted its own authors. CISA’s machine-readable assessment of both PaperCut CVEs, timestamped August 28, records exploitation as “none” — written a day after PaperCut told its own customers they were under attack. Wordfence’s advisory for a CVSS 9.8 unauthenticated remote code execution flaw in the Avada theme conditions exploitation on site content an administrator has to have created, while the researchers who found it told reporters that any site with the theme installed is exploitable. GiveWP shipped the fix for an unauthenticated CVSS 10.0 remote code execution chain and called it “additional hardening” in its changelog. TranslatePress’s fixing release does not appear in the vendor changelog at all. In each case the authoritative document disagrees with something the same organization said out loud.

    Order of business after PaperCut. Gitea’s three-day federal deadline for CVE-2026-60004 expired on August 28 with Shadowserver counting 8,393 vulnerable instances the day before; the fix shipped on July 27, so this is a patch nobody applied rather than a patch nobody had. Then ServiceNow, which published four of its own CVEs on August 27 and scored three of them at a flat CVSS v4.0 10.0 with byte-identical vectors, all unauthenticated, all citing one knowledge base article. Then the WordPress set — GiveWP on more than 100,000 sites, Avada, and TranslatePress on more than 400,000, where what leaked was administrator password-reset links readable by any visitor. Cosmos EVM operators should read the post-mortem: Cosmos Labs confirmed on August 13 that every EVM chain was exposed and began notifying operators on August 21, after exploitation had begun. Below that, VulnCheck’s two new Zbtlink router implants — one a service that runs commands as root on an unauthenticated UDP port, though VulnCheck’s own internet-facing count is 203 devices — and the deleted Log4j deserialization report that Apache says is a known non-finding while the public exploit labs stay up.

    Three disclosures moved today without handing anyone a task: ATF confirmed a breach of a standalone system that the Justice Department has already designated a major incident, Berlin confirmed it is being extorted and rejected the ultimatum eleven days after announcing the compromise without mentioning it, and Hasbro’s employee notification letters surfaced in a state attorney general filing.

    Still open. CISA’s assessment of the PaperCut chain still records exploitation as “none” — the field that drives federal prioritization, on the one item confirmed under attack. ATF has not said what was on the standalone system, and no data has appeared. Zbtlink disputes VulnCheck’s characterization, and no CVE has been assigned to either implant. Hasbro’s own public account of the March breach has not moved since April 4, while the letters go out now. And the ICO has asked MAG not to name the group behind the theft, so the attribution most readers want is the one thing that will not be published.

  • Cosmos Labs confirmed every EVM chain was exposed on August 13 and notified operators on August 21, after exploitation had begun

    Cosmos Labs confirmed every EVM chain was exposed on August 13 and notified operators on August 21, after exploitation had begun

    Cosmos Labs’ own post-mortem, published August 28, says a bug reported in April was quietly patched in May under a mistaken conclusion about which chains it touched — and that the team confirmed on August 13 that every Cosmos EVM chain was exposed, eight days before it began privately notifying operators.

    What happened

    On August 28, 2026, the Cosmos EVM project published GHSA-7g4w-cg88-2cq2, “Balance underflow in EVM StateDB,” rated critical, with no CVE assigned. The advisory names the affected ranges as versions below 0.6.2 and versions from 0.7.0 up to but not including 0.7.2. The patched versions are 0.6.2 and 0.7.2.

    The mechanism, in the advisory’s own words: “The EVM StateDB sees only an account’s spendable balance. When a vesting account delegates an amount greater than its spendable balance (i.e., dips into its locked balance, which x/staking and the staking precompile permit), the SubBalance write-back on the StateDB subtracts the full delegated amount from a smaller spendable figure. The subtraction is unchecked and wraps the balance to ≈2²⁵⁶.”

    That is an integer underflow reachable through ordinary, permitted staking behavior. An account that delegates into its locked balance ends up, from the EVM’s point of view, holding roughly the entire representable range of a 256-bit integer. Nothing is injected and no privilege is escalated. The account does what the staking module explicitly allows, and the balance ledger the EVM reads wraps around.

    On workarounds the advisory is unusually blunt: “There is no configuration-only mitigation. If an operator cannot upgrade immediately, halt the chain rather than attempt a coordinated governance upgrade.” The advisory credits the Cosmos bug bounty program, naming @AshmitSh4rma and additional independent researchers.

    The timeline is where this stops being an ordinary critical bug. Per the post-mortem as reported by The Hacker News on August 28: the vulnerability was reported through the bug bounty program on April 25, 2026. An initial patch was merged to main on May 15, and a further balance fix on May 20. On August 13, Cosmos Labs confirmed that all Cosmos EVM chains were affected. Patched releases v0.6.2 and v0.7.2 went out on August 19. The first private notification to chain operators went out on August 21. Exploitation ran from August 20 through August 25.

    The post-mortem states the reason the May patch went out quietly as a technical misjudgment: “We were unable to reproduce the vulnerability on 18-decimal networks and incorrectly concluded that it affected only non-18-decimal networks.” Most Cosmos EVM chains use 18 decimals. On that reading the bug looked like a narrow problem for a few unusual chains rather than a defect in every deployment, and the fix was merged as a normal change rather than shipped as an emergency release.

    Cosmos Labs went public on August 24. The Defiant, reporting the next day, records it saying at 1:06 p.m. EST that “an ongoing security incident has impacted users of the Cosmos EVM module,” and advising chains it was in contact with to “request that validators halt their chains.”

    The loss figures do not agree, and the disagreement is large. The post-mortem puts the total at approximately $5.72 million across six chains, split roughly $2.87 million moved through decentralized exchanges and $2.85 million through centralized ones. The Defiant, four days earlier, named three chains and reported KiiChain alone losing 148 million KII, which it valued at about $9.7 million — more than the vendor’s later total for all six chains combined. It also reported TAC losing 2,985,651,403 TAC, which it put at roughly 62 percent of circulating supply, and MANTRA disclosing an undisclosed amount from two managed wallets. A separate account, at Protos, framed the bug as affecting four blockchains.

    Three, four, or six chains; $5.72 million or considerably more. Token-denominated losses on thin markets and realized attacker proceeds are not the same quantity, and “62 percent of circulating supply” converts to dollars very differently depending on when you convert it. We are not picking one. Both are on the record. Chain status as of August 25: MANTRA halted August 20 and restarted August 22; TAC and KiiChain both halted August 22 and still frozen.

    Why it matters

    The interesting failure here is not the underflow. Unchecked subtraction on a balance is an old bug with an old fix, and the guard that went into SubBalance is the obvious one. The interesting failure is that the correct patch existed in the main branch from May 15 and did not reach the chains that needed it for three months, because the team’s model of who was affected was wrong and nothing in the process was designed to catch that.

    A silent patch is a bet. The bet is that quiet merging gets the fix into the next ordinary release before anyone reading the commit history works out what it fixes. That bet is defensible when the affected population is small, reachable, and already being told directly. It becomes indefensible the moment the affected population turns out to be everyone, because the commit is public the whole time and the people who read commits adversarially are not waiting for a release note.

    The specific trap is worth naming, because it will recur outside blockchain infrastructure: the team tried to reproduce the bug on the common configuration, failed, and treated failure-to-reproduce as evidence of non-applicability. Those are different claims. Failing to trigger an underflow on an 18-decimal network says something about the test, the harness, or the particular path exercised. It does not establish that the arithmetic is safe there. A negative reproduction result narrows nothing unless you know why the reproduction failed.

    The disclosure-policy criticism follows from that. Cosmos Labs’ published policy, per the reporting, calls for emergency mitigations and private fix distribution where a defect puts a whole network class at risk. From August 13 the project knew it had exactly that. Patched releases came on August 19; operator notification started on August 21; exploitation started on August 20. The gap that matters is not April to August, which is explained by the misjudgment. It is August 13 to August 21, which is not. Eight days after confirming that every chain running your module can have its balance ledger wrapped, the people who run those chains had not been told.

    There is also a governance point buried in the workaround text that deserves attention beyond Cosmos. “Halt the chain rather than attempt a coordinated governance upgrade” is the advisory conceding that its own normal upgrade path is too slow to use in an emergency. The process that makes an upgrade legitimate also makes it slow, and slow is the wrong property when the exploit is live. Any organization whose change control requires a quorum should ask what its own emergency bypass is, and whether anyone has ever used it.

    Finally, the absence of a CVE. This is a critical, actively exploited defect in a shared module carrying a GHSA identifier and no CVE. Tools that track Go module advisories via GHSA will see it; those that reconcile to CVE alone will not. That is a concrete reason not to treat CVE coverage as a proxy for vulnerability coverage.

    What to do

    If you run a Cosmos EVM chain, upgrade to v0.6.2 or v0.7.2 or later. Versions below 0.6.2, and 0.7.0 and 0.7.1, are affected. If you cannot upgrade now, the advisory’s instruction is to halt the chain rather than route the fix through governance.

    Check whether any account on your chain has a balance in the neighborhood of 2²⁵⁶, and review delegation events from vesting accounts where the delegated amount exceeded the spendable balance. The exploitation window the post-mortem gives is August 20 to 25, 2026, but that is the window in which losses were observed, not a guarantee about when the condition was first reachable — the defect has been present in shipped versions since well before then.

    If you consume Go modules and rely on vulnerability scanning, confirm your tooling ingests GitHub Security Advisories directly and does not filter to entries carrying CVE identifiers. This advisory has no CVE.

    Sourcing note

    Checked: GHSA-7g4w-cg88-2cq2 on GitHub, the project’s own advisory, published August 28, 2026 — the source for the affected and patched version ranges, the impact text, the workaround instruction, and the credits, all quoted above verbatim.

    The incident timeline and the quotation “We were unable to reproduce the vulnerability on 18-decimal networks and incorrectly concluded that it affected only non-18-decimal networks” come from Cosmos Labs’ post-mortem as reported by The Hacker News on August 28, 2026. We were not able to reach the post-mortem document itself, so the dates in the timeline section — April 25, May 15, May 20, August 13, August 19, August 21, and the 20–August 25 exploitation window — are reported at one remove from the vendor’s own text. They are attributed to the vendor by the outlet, not independently confirmed against the vendor’s page by us. Treat them accordingly.

    Chain-level halt dates and loss figures come from The Defiant, August 25, 2026, reporting on the affected chains’ disclosures. The August 24 Cosmos Labs quotation and its timestamp come from the same report. The $5.72 million across six chains comes from the post-mortem via The Hacker News. These figures conflict and are presented as conflicting; we have not reconciled them and do not endorse either.

    Unresolved: no CVE has been assigned. Cosmos Labs has named no attacker and neither have we. Whether TAC and KiiChain have restarted since August 25 is not established here. The disclosure policy said to require emergency mitigation is described in secondary reporting; we did not retrieve it.