Cosmos-EVM-Lücke leert sechs Netzwerke – ein Konfigurationsfix reicht nicht
Cosmos Labs hat am 28. August 2026 offengelegt, dass Angreifer zwischen dem 20. und 25. August eine kritische Schwachstelle in Cosmos EVM auf sechs Cosmos-basierten Blockchains ausnutzten. Der Post-Mortem von Cosmos Labs beziffert die anschließend über dezentrale und zentrale Börsen getauschten oder verkauften Werte auf rund 5,72 Millionen US-Dollar.
Betroffen sind Versionen vor 0.6.2 sowie die Versionen 0.7.0 und 0.7.1. Betreiber müssen auf mindestens 0.6.2 beziehungsweise 0.7.2 wechseln und die Änderung als koordiniertes Netzwerk-Upgrade aktivieren. Eine reine Konfigurationsänderung genügt nicht.
Welche Versionszweige betroffen sind
Das am 28. August veröffentlichte offizielle Sicherheits-Advisory ordnet die verwundbaren und korrigierten Releases eindeutig zu:
- Versionen vor 0.6.2: betroffen; im 0.6-Zweig ist mindestens 0.6.2 erforderlich.
- Versionen 0.7.0 und 0.7.1: betroffen; im 0.7-Zweig ist mindestens 0.7.2 erforderlich.
- Version 0.6.2: enthält den in den älteren Release-Zweig zurückportierten Schutz.
- Version 0.7.2: enthält den Schutz im neueren Release-Zweig.
Ein korrigierter Stand im Repository schützt eine produktive Blockchain noch nicht automatisch. Maßgeblich ist die tatsächlich ausgeführte Version der jeweiligen Chain. Weil der Patch die Zustandsverarbeitung verändert, müssen die Validatoren den Wechsel gemeinsam und zu einem festgelegten Zeitpunkt vollziehen; ein isolierter Austausch der Binärdatei kann zu unterschiedlichen Zustandsberechnungen führen.
Damit unterscheidet sich die Lage von einem gewöhnlichen Softwareupdate auf einem einzelnen Server. Jede betroffene Blockchain benötigt einen eigenen Upgrade-Plan, die passende Binärdatei und die koordinierte Aktivierung durch ihre Netzwerkteilnehmer.
Wie der Kontostand-Unterlauf den Diebstahl ermöglichte
Die Schwachstelle entstand bei der Abstimmung zweier Kontostandsmodelle. Die EVM-StateDB bildet nur das frei verfügbare Guthaben eines Kontos ab. Ein Vesting-Konto im Cosmos SDK kann daneben gesperrtes Guthaben besitzen, das über das Staking-Modul und das Staking-Precompile delegiert werden darf.
Delegierte ein solches Konto mehr als den in der StateDB sichtbaren, frei verfügbaren Betrag, zog die Funktion SubBalance die größere Summe von der kleineren ab. Die fehlende Unterlaufprüfung ließ den Wert dabei auf ungefähr 2²⁵⁶ umschlagen. Der Patch ergänzt eine Prüfung an diesem Schreibvorgang.
Für den Angriff wurde dieser künstlich große Wert in derselben Transaktion mit einem Überlauf auf einem Zielkonto kombiniert. Die Täter konnten dadurch reales Guthaben eines Kontos mit hohem Bestand an sich bringen, während die Nettoänderung des gesamten Token-Angebots null blieb. Ein bösartiger Smart Contract auf einer vorbereiteten Vesting-Adresse verband beide Schritte.
Die Folgen unterschieden sich zwischen den Versionszweigen. Im 0.6-Zweig konnte die enorme Mint-Operation einen Überlauf des Gesamtangebots und damit einen Stillstand der Chain auslösen. Der 0.7-Zweig setzte Kontostände direkt im x/bank-Modul und konnte manipulierte Werte akzeptieren, sofern sie die erforderliche Zahlenkonvertierung überstanden. Ausgangspunkt war in beiden Fällen derselbe ungeprüfte Unterlauf.
Warum das Staking-Precompile abzuschalten nicht ausreicht
Das Deaktivieren des Staking-Precompiles entfernt zwar den wichtigsten bekannten Auslösepfad, beseitigt aber weder den fehlerhaften Code noch ersetzt es den Patch. Das Advisory nennt deshalb ausdrücklich keine reine Konfigurationslösung.
Betreiber, die das Upgrade nicht sofort durchführen können, sollen die Chain anhalten. Das ist von einem Governance-Beschluss ohne Softwarewechsel zu unterscheiden: Nur die korrigierte Version verhindert den ungeprüften Unterlauf im betroffenen Codepfad. Das Upgrade selbst muss anschließend weiterhin koordiniert erfolgen, weil es den Netzwerkzustand berührt.
Für Validatoren und Chain-Teams folgt daraus eine klare Trennung der Aufgaben: Sie müssen die laufende Version feststellen, den passenden Release-Zweig auswählen und die gemeinsame Aktivierung organisieren. Außerdem ist zu prüfen, ob vor dem Wechsel bereits verdächtige Transaktionen ausgeführt wurden. Der Patch schließt den verwundbaren Pfad für künftige Transaktionen, macht bereits verschobene Token jedoch nicht automatisch rückgängig.
Tokenhalter können das Update nicht selbst installieren. Für sie ist entscheidend, ob die konkrete Chain ihr Upgrade abgeschlossen hat und ob Brücken oder Börsen Einzahlungen, Auszahlungen und Transfers wieder freigegeben haben. Die bloße Veröffentlichung von 0.6.2 oder 0.7.2 belegt diesen chain-spezifischen Betriebsstatus nicht.
Schadensbilanz und Aufarbeitung sind noch nicht abgeschlossen
Cosmos Labs teilt die beobachteten Erlöse in ungefähr 2,87 Millionen US-Dollar aus über Bridges transferierten und auf dezentralen Börsen getauschten Vermögenswerten sowie geschätzte 2,85 Millionen US-Dollar aus Verkäufen über zentrale Börsen auf. Die zugrunde liegenden Angaben der betroffenen Chains seien mit öffentlich verfügbaren Daten vereinbar, aber nicht unabhängig geprüft. Zum Veröffentlichungszeitpunkt waren gemeldete Konten auf zentralen Börsen eingefroren; eine Rückzahlung war damit nicht bestätigt.
Eine unabhängige Einordnung von The Hacker News bestätigt die sechs angegriffenen Blockchains, den Zeitraum vom 20. bis 25. August und die Notwendigkeit eines koordinierten, zustandsverändernden Upgrades. Öffentlich benannt sind MANTRA, TAC und KiiChain; drei weitere angegriffene Netzwerke wurden im Cosmos-Bericht nicht namentlich aufgeführt.
Technisch ist der Mindeststand damit klar: Verwundbare Installationen benötigen mindestens 0.6.2 oder 0.7.2 und eine koordinierte Aktivierung. Offen bleiben die vollständige finanzielle Bilanz, der Upgrade-Status einzelner Netzwerke und der Ausgang der Ermittlungen zu den eingefrorenen Börsenkonten.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.