Between August 20 and August 25, 2026, attackers drained funds from six separate blockchains by exploiting a single flaw in the shared Cosmos EVM module. The vulnerability, tracked as GHSA-7g4w-cg88-2cq2, is rated Critical by Cosmos Labs. It has no CVE identifier, no CVSS score, and no weakness classification attached to it. That gap matters more than it sounds like it should, because it’s a preview of where cybersecurity risk management keeps failing: the things that don’t fit the standard scoring pipeline get treated as if they don’t exist, right up until they get exploited.

Illustration representing the Cosmos EVM blockchain exploit
A balance-handling flaw in a shared Cosmos EVM module let attackers drain six chains before every deployment patched.

August 20-25: Six Chains, One Shared Module, One Overdue Patch

The Cosmos EVM module is code that multiple independent Cosmos-based blockchains reuse to support Ethereum-compatible smart contracts. That’s the appeal of a shared module: you don’t rebuild the wheel for every chain. It’s also the danger. A balance-handling flaw in versions before 0.6.2 meant that once one attacker figured out how to exploit it, every chain still running the vulnerable code was exposed at the same time, with the same technique.

Cosmos Labs knew about the flaw before the exploitation started. That’s the part worth sitting with. This wasn’t a zero-day sprung on defenders with no warning; it was a known weakness in shared infrastructure that some deployments patched and others didn’t get to fast enough. Six chains got hit inside a five-day window while the ecosystem was mid-rollout on a fix. That’s not a failure of detection. It’s a failure of coordination and urgency, the same failure pattern that shows up whenever a shared library, shared dependency, or shared module sits underneath more systems than any one team is watching.

No CVE, No CVSS, No Urgency: How Cybersecurity Scoring Systems Miss Real Risk

Most vulnerability management programs are built around feeds: NVD entries, CVSS scores, vendor advisories that slot neatly into a ticketing system. That model works fine for a lot of cybersecurity operations, and it’s not going away. But it has a blind spot, and the Cosmos EVM advisory sits right in it. A GHSA identifier without a CVE doesn’t trigger the same automated scanners, doesn’t show up in the same compliance dashboards, and doesn’t get the same instinctive “drop everything” reaction from a team trained to prioritize by score.

Smart contract and blockchain infrastructure isn’t the only place this happens. Internal tooling, homegrown scripts, forked open-source components, and anything published through a security advisory rather than a formal CVE process all suffer the same fate: real, exploitable, critical-rated risk that doesn’t move the needle in a system built to react to numbers. If your incident response plan only activates once something clears a CVSS threshold, you’ve already built a gap that attackers are financially motivated to find.

The Quantum Threat Is the Same Blind Spot, Just Slower

There’s a second story running in parallel this week that’s a slow-motion version of the same problem. Tenable’s research on cryptographic inventory lays out the “harvest now, decrypt later” tactic: adversaries are intercepting and storing encrypted traffic today, banking on quantum computers eventually being able to crack the RSA, ECC, and Diffie-Hellman algorithms protecting it. Executive Order 14412 has set 2030 and 2031 deadlines for federal agencies to migrate high-value assets to post-quantum cryptography. AES-256 holds up fine against quantum attacks; the asymmetric algorithms securing your TLS handshakes and SSH sessions do not.

No active exploit is hitting your firewall over this today, which is exactly why it gets deprioritized the same way the Cosmos EVM flaw did before it got exploited. There’s no CVE for “your RSA-2048 traffic being harvested right now for decryption in 2032.” There’s just a slow accumulation of stolen ciphertext sitting in someone else’s data center, waiting. Both stories point at the same organizational failure: threat detection and prioritization systems built around known, scored, catalogued threats miss the risks that are real but don’t file the right paperwork.

Diagram illustrating cryptographic inventory and post-quantum migration strategy
Harvest-now-decrypt-later attacks exploit the same blind spot as unscored vulnerabilities: risk without a familiar label gets deprioritized.

Building a Risk Process That Doesn’t Wait for a Score

None of this means CVSS is useless or that you should ignore your patch management pipeline. It means the pipeline can’t be the only gate. Defense in depth has to include a process for catching risk that shows up outside the normal feed, whether that’s a shared-library advisory with no CVE, a cryptographic weakness with no active exploit yet, or an internal finding nobody formally filed.

A few concrete moves that hold up regardless of your stack:

  • Track GitHub Security Advisories (GHSA), vendor blog posts, and mailing lists for every shared library or module you depend on, not just your CVE feed. Assign someone ownership of that watch, not “everyone.”
  • Build a cryptographic inventory now: catalog every service using RSA, ECC, or Diffie-Hellman for key exchange, and flag which ones handle data with a shelf life past 2030.
  • Treat “no CVSS score yet” as a data gap, not a green light. Score internally using your own impact and exposure criteria before a formal number ever arrives.
  • Harden the assumption of shared code. If a module is reused across your environment the way the Cosmos EVM module was reused across six chains, one patch delay anywhere becomes an incident everywhere.
  • Fold unscored and pre-CVE findings into the same incident response runbook you use for scored vulnerabilities, so response time doesn’t depend on which system flagged it.

Security hardening built entirely around external scoring systems will always lag the risks that don’t fit the form. The teams that get burned aren’t the ones without a firewall or without brute-force protections on their exposed services; they’re the ones whose whole risk model stops at the edge of what a scanner already knows to look for.

Sources

Take Control of Your Server Security

Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.

Secure. Automated. Lightweight.

Stay up to date with the latest news, releases and more.

Take Control of Your Server Security

Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.

Secure. Automated. Lightweight.