Cosmos EVM, kritische Schwachstelle ohne CVE: sechs Blockchains betroffen, der stille Patch hat den Exploit nicht gestoppt

Am 28. August 2026 veröffentlichte Cosmos Labs einen GitHub-Advisory und ein Post-Mortem für eine kritische Schwachstelle im gemeinsamen Cosmos-EVM-Modul, der Umgebung für die Ausführung Ethereum-kompatibler Smart Contracts im Cosmos-SDK-Ökosystem. Die als GHSA-7g4w-cg88-2cq2 identifizierte Schwachstelle wurde vom Hersteller als „Critical“ eingestuft, erhielt jedoch keine CVE-Kennung, keine CWE-Klassifizierung und keinen CVSS-Score. Betroffen sind alle Versionen vor 0.6.2 sowie die Versionen 0.7.0 bis 0.7.1. Die Korrekturen wurden am 19. August in den Versionen v0.6.2 und v0.7.2 veröffentlicht, das Update ist jedoch state-breaking und erfordert ein koordiniertes Netzwerk-Upgrade. Zwischen dem 20. und 25. August wurde die Schwachstelle aktiv gegen sechs Blockchains ausgenutzt, mit geschätzten wirtschaftlichen Verlusten in Millionenhöhe.

Wie der Angriff funktioniert: Underflow, Vesting-Konten und „aufgeblähte“ Salden

Die Schwachstelle entsteht im Code, der den Zustand der EVM mit dem x/bank-Modul des Cosmos SDK abgleicht. Die StateDB der EVM erfasst nur den verfügbaren Saldo eines Kontos. Bei Vesting-Konten enthält der SDK-Zustand jedoch sowohl einen verfügbaren als auch einen gesperrten Saldo, der über das x/staking-Modul und die Staking-Precompile delegiert werden kann.

Wenn ein Vesting-Konto mehr als seinen verfügbaren Saldo delegiert, subtrahiert die nachfolgende Schreiboperation den gesamten delegierten Betrag von einem niedrigeren Saldo: Die Subtraktion wird nicht geprüft und der Wert läuft in einen Underflow, der sich auf etwa 2^256 umschlägt. Der anschließende Abgleich prägt bei einer positiven Differenz und verbrennt bei einer negativen Differenz. Ein Angreifer kann daher einen endlichen Betrag von einem Konto mit „umgeschlagenem“ Saldo verschieben und einem Opfer eine Menge in Höhe von 2^256 minus dessen Saldo senden, sodass beim Abgleich die realen Guthaben des Opfers verbrannt werden.

Auf Chains der Linie 0.6.x erfolgt die Prägung oder Verbrennung im zugrunde liegenden SDK-Ledger: Eine hohe Prägung verursacht einen Overflow des Gesamtangebots und stoppt die Chain. Auf den Linien 0.7.x werden die Salden direkt in x/bank gesetzt und akzeptieren Änderungen, die die Konvertierung von uint256 zu int256 überstehen. In beiden Fällen wird die gesamte Operation in einer einzigen Transaktion mit einer Netto-Angebotsveränderung von null ausgeführt, ausgehend von einem Vertrag, der an einer vorberechneten Adresse bereitgestellt und zuvor in ein Vesting-Konto umgewandelt wurde. Die Ausnutzung setzt voraus, dass die Chain die erlaubnisfreie Erstellung von Vesting-Konten zulässt.

Die Chronologie: Meldung im April, Bestätigung im August, stiller Patch

Die Schwachstelle wurde am 25. April über das Bug-Bounty-Programm von Cosmos Labs gemeldet. Zunächst bewertete das Team sie als ohne Risiko für Gelder in Live-Netzen: Es konnte sie auf Netzen mit 18 Dezimalstellen nicht reproduzieren und schloss fälschlich, dass sie nur Netze mit anderen Dezimalstellen betreffe. Erst am 13. August kam die Bestätigung, dass alle Cosmos-EVM-Chains unabhängig von der Dezimalkonfiguration betroffen waren.

Die primäre Korrektur – ein Underflow-Guard im Write-back SubBalance der StateDB – war bereits mit PR #1176 eingeführt und am 15. Mai in den main-Branch gemergt worden. Die Backports erfolgten wesentlich später: PR #1253 für die Linie v0.6.x und PR #1254 für v0.7.x, die zu den Releases v0.6.2 und v0.7.2 vom 19. August führten.

Der Fix durchlief den Silent-Patch-Prozess, den Cosmos Labs für Probleme reserviert, die in der Produktion keinen Verlust von Geldern verursachen. Die Richtlinie sieht Notfall-Mitigationen oder private Verteilung für unmittelbare Risiken vor, doch in diesem Fall hielt das Team ein stilles Vorgehen für sicher, weil der Patch bereits öffentlich im main-Branch lag und keine bekannte Ausnutzung vorlag.

Die Einschätzung erwies sich als falsch. Am 20. August um 07:16 UTC, acht Stunden und fünfzehn Minuten nach Veröffentlichung der Releases, beschrieb eine öffentliche PR im Fork von Push Chain detailliert die Schwachstelle und den Ausnutzungspfad. Elf Stunden und fünfzig Minuten später, um 19:06 UTC, begann der erste Angriff gegen MANTRA. Die erste private Benachrichtigung von Cosmos Labs per sicherer E-Mail erfolgte erst am 21. August um 03:36 UTC, etwa zwei Stunden nachdem MANTRA die Ausnutzung gemeldet hatte.

Auswirkungen: Sechs Chains, Millionen Dollar auf Börsen verkauft

Cosmos Labs sind sechs Blockchains bekannt, auf denen der Exploit aktiv eingesetzt wurde. MANTRA ist die einzige, die ausdrücklich als erstes Opfer genannt wird. Die Angreifer verkauften rund 2,87 Millionen US-Dollar an betroffenen Vermögenswerten auf dezentralen Börsen, basierend auf Preisen vom 19. August und von den Chains selbst gelieferten, nicht unabhängig verifizierten Zahlen. Weitere 2,85 Millionen US-Dollar wurden auf zentralisierten Börsen verkauft, eine Schätzung auf Basis öffentlicher Volumendaten.

Das Cosmos-Ökosystem umfasst über 115 bekannte öffentliche Blockchains, doch Cosmos Labs verfügt über kein vollständiges Register der Netze, die seine Software betreiben. Diese Lücke hatte bereits im Juli Downstream-Anbieter gezwungen, Fehler in eingebundenen Dateisystemen zu patchen. Während des Vorfalls entdeckte das Team elf Cosmos-EVM-Implementierungen, die sich nie bei seinen Sicherheitskanälen registriert hatten.

Was Betreiber tun müssen: Patch, Workarounds und Überprüfungen

Das offizielle Advisory empfiehlt, auf v0.6.2 oder v0.7.2 oder höher zu aktualisieren und die Änderung als koordiniertes Netzwerk-Upgrade anzuwenden, da sie state-breaking ist. Falls eine sofortige Aktualisierung nicht möglich ist, wird empfohlen, die Chain anzuhalten, anstatt ein koordiniertes Governance-Upgrade zu versuchen. Es gibt keine rein konfigurationsbasierte Mitigation: Das Deaktivieren der Staking-Precompile entfernt den Hauptaktivierungspfad, ersetzt aber nicht den Patch.

The Hacker News hat weitere operative Schritte für Entwickler aufgeführt. Erstens: die Vorbedingung schließen, indem im Ante-Handler die Nachrichten MsgCreateVestingAccount, MsgCreatePermanentLockedAccount und MsgCreatePeriodicVestingAccount abgelehnt werden, ohne die in der Genesis definierten Vesting-Konten anzutasten. Zweitens: den Live-Codepfad auf einem Fork überprüfen – ein Cherry-Pick, der nur den exportierten Helfer korrigiert, kann eine nicht exportierte duplizierte Kopie unverändert lassen, während alle Tests weiterhin bestehen. Drittens: die beiden Korrekturen anwenden, die das Advisory auslässt: den Snapshot des gesperrten Saldos (PR #1187, gemergt am 20. Mai) und den Guard für Modulkonten (Commit 3524ebc). Der Guard lehnt Modulkonten bedingungslos ab, was EVM-Aufrufe von einem Modulkonto unterbricht. Schließlich sollte jedes Team einen Sicherheitskontakt bei Cosmos Labs registrieren.

ZetaChain hat die drei Korrekturen am 21. August übernommen und festgestellt, dass der Cherry-Pick den Live-Pfad des Forks nicht korrigierte, da der Fork duplizierte nicht exportierte Helfer enthielt. Warden Protocol blockierte zwei Tage später die Erstellung von Vesting-Konten vollständig: Auf Warden sind Vesting-Konten die einzige Quelle gesperrter Salden und keine Funktionalität hängt von ihrer Erstellung ab, sodass das Entfernen dieses Pfads die Vorbedingung schließt, ohne sich auf die Korrektheit der Rekonstruktion zu verlassen.

Silent Patch und Präzedenzfälle: 37 Schwachstellen ohne öffentliche Beschreibung

Das Advisory dokumentiert nur eine Upstream-Änderung: den Underflow-Guard aus PR #1176. Im selben Repository existieren jedoch zwei weitere Saldenkorrekturen, die nicht erwähnt werden: PR #1187, die den gesperrten Saldo eines Kontos snapshotet, um den Banksaldo nach einer Precompile-Änderung korrekt zu rekonstruieren, und Commit 3524ebc mit dem Titel „Merge commit from fork“, der jeden Versuch ablehnt, den Saldo eines Modulkontos zu setzen. Die Backports von PR #1187 wurden innerhalb von vierundzwanzig Stunden auf beiden Release-Linien geöffnet und gemergt, während der Backport von PR #1176 etwa neunzig Tage später folgte.

Die Release-Notes von v0.6.2 und v0.7.2 geben an, wichtige Sicherheitskorrekturen zu enthalten, lassen aber den Sicherheits-Backport aus den Changelogs weg. The Hacker News bestätigte am 29. August, dass keiner der beiden Releases die Pull Requests auflistet, die ihn übertragen.

Cosmos Labs erklärte, in den vergangenen 13 Monaten still Patches für 37 Schwachstellen verteilt zu haben, ohne dass Downstream-Entwickler die Ausnutzungspfade öffentlich beschrieben. Die Entscheidung, den Patch nach der Bestätigung vom 13. August, dass alle Chains betroffen waren, nicht privat zu verteilen, steht nun im Zentrum der Kritik. The Hacker News hat Cosmos Labs um einen Kommentar gebeten und wartet auf eine Antwort.