Eine kritische Sicherheitslücke im gemeinsamen Cosmos-EVM-Modul wurde zwischen dem 20. und 25. August 2026 ausgenutzt, um Gelder aus sechs Blockchains abzuziehen – obwohl Cosmos Labs bereits zwei Wochen zuvor bestätigt hatte, dass alle EVM-Chains verwundbar waren. Die Schwachstelle mit der Kennung GHSA-7g4w-cg88-2cq2 wurde von Cosmos Labs als kritisch eingestuft, jedoch ohne CVE-Referenz oder CVSS-Score veröffentlicht. Betroffen waren Versionen unter 0.6.2 sowie ab 0.7.0 vor 0.7.2; die korrigierten Versionen 0.6.2 und 0.7.2 wurden am 19. August bereitgestellt. Chain-Betreiber wurden angewiesen, ein koordiniertes Netzwerk-Upgrade durchzuführen, da der Patch zustandsändernd ist.
Fehleinschätzung und verspätete Warnung
Die Verwundbarkeit wurde Cosmos Labs bereits am 25. April 2026 über das Bug-Bounty-Programm gemeldet. Das Team bewertete sie damals als ungefährlich für Live-Netzwerke, da es nicht gelang, den Exploit auf Ketten mit 18 Dezimalstellen zu reproduzieren. „Wir kamen fälschlicherweise zu dem Schluss, dass nur Netzwerke mit abweichender Dezimalkonfiguration betroffen sind“, heißt es im am 28. August veröffentlichten Post-Mortem. Erst am 13. August erkannte das Team, dass sämtliche Cosmos-EVM-Chains verwundbar sind – unabhängig von der Dezimalstellenanzahl.
Trotz dieser Erkenntnis wurde der Fix über den öffentlichen Stillen-Patch-Prozess ausgerollt, den Cosmos Labs für Probleme reserviert, die auf Produktionsketten nicht zu Geldverlust führen. In der eigenen Bug-Bounty-Richtlinie steht dagegen: „Wenn ein Problem eine unmittelbare oder netzwerkweite Gefahr darstellt, leitet Cosmos Labs Notfallmaßnahmen, private Patch-Verteilung oder koordinierte Upgrades ein, bevor eine öffentliche Offenlegung erfolgt.“ Genau das unterblieb. Der Patch war seit 19. August öffentlich verfügbar, die erste private Benachrichtigung an betroffene Chains verschickte Cosmos Labs jedoch erst rund zwei Stunden, nachdem MANTRA den ersten Exploit gemeldet hatte – am 21. August um 03:36 UTC.
Technischer Mechanismus des Exploits
Der Fehler liegt in der Abstimmung zwischen dem Ethereum Virtual Machine (EVM)-Zustand und dem Cosmos-SDK-Modul x/bank. Der EVM-StateDB erfasst nur das auszahlbare Guthaben eines Kontos, während Vesting-Konten im SDK-Zustand sowohl ein auszahlbares als auch ein gesperrtes Guthaben führen. Sowohl x/staking als auch der Staking-Precompile erlauben es, den gesperrten Anteil zu delegieren.
Delegiert ein Vesting-Konto mehr, als sein auszahlbares Guthaben beträgt, zieht der Rückschreibevorgang nach der Delegation den vollen delegierten Betrag vom kleineren auszahlbaren Saldo ab. Die Subtraktion ist ungeprüft: Der Saldo läuft auf etwa 2256 über. Die anschließende Reconciliation mint Token bei positiver Differenz und burned bei negativer. Ein Angreifer kann so aus dem überlaufenden Konto Gelder abziehen oder einem Opferkonto eine Summe von 2256 minus dessen Guthaben senden, sodass die Reconciliation die echten Bestände des Opfers verbrennt. Bei Chains auf Version 0.6.x führt ein großes Mint aufgrund des Supply-Overflows zum Kettenstillstand; Chains auf 0.7.x setzen Salden direkt in x/bank und akzeptieren Änderungen, die eine Konvertierung von uint256 nach int256 überstehen. Beide Varianten laufen innerhalb einer einzigen Transaktion mit einer Netto-Supply-Änderung von null.
Der Exploit setzt voraus, dass die Chain die uneingeschränkte Erstellung von Vesting-Konten erlaubt. Der Angreifer deployt einen Vertrag auf eine vorausberechnete Adresse und wandelt diese in ein Vesting-Konto um.
Lückenhafte Patch-Strategie und öffentlich gewordene Details
Obwohl die Sicherheitslücke als kritisch eingestuft wurde, verzögerte sich der Backport des zentralen Fixes deutlich. Der Underflow-Schutz in SubBalance wurde bereits am 15. Mai über Pull Request #1176 in den Hauptzweig gemergt, der Backport in die Release-Lines 0.6.x und 0.7.x folgte jedoch erst am 13. August – fast drei Monate später. Zwei weitere notwendige Korrekturen, die in der Sicherheitsadvisory nicht genannt werden, waren ebenfalls bereits im Repository vorhanden: Pull Request #1187 (gesperrte Guthaben als Snapshot) und Commit 3524ebc (Abweisung von Modulkonten-Transaktionen). Die Versionshinweise zu v0.6.2 und v0.7.2 erwähnen die Sicherheits-Backports nicht im Changelog. Das Unternehmen erklärte, in den letzten 13 Monaten 37 Schwachstellen still gepatcht zu haben, ohne dass Exploit-Pfade öffentlich beschrieben wurden. Im aktuellen Fall veröffentlichte jedoch ein Entwickler von Push Chain am 20. August um 07:16 UTC einen öffentlichen Pull Request mit detaillierter Beschreibung der Schwachstelle – nur acht Stunden nachdem die korrigierten Versionen ausgeliefert worden waren. Der erste Angriff auf MANTRA erfolgte rund zwölf Stunden später.
Konsequenzen und Handlungsempfehlungen für Betreiber
Cosmos Labs rät Betreibern zu folgenden Maßnahmen, die über ein reines Upgrade hinausgehen:
- Upgrade auf v0.6.2 oder v0.7.2 – als koordiniertes Netzwerk-Upgrade, da der Patch zustandsändernd ist
- Kette anhalten statt Governance-Abstimmung – wer nicht sofort updaten kann, soll die Blockproduktion stoppen; es gibt keine reine Konfigurationslösung
- Vorbedingung schließen – die Nachrichten MsgCreateVestingAccount, MsgCreatePermanentLockedAccount und MsgCreatePeriodicVestingAccount im Ante-Handler ablehnen
- Live-Code-Pfad auf einem Fork verifizieren – ein Cherry-Pick kann eine duplizierte unexportierte Kopie ungepatcht lassen, während alle Tests bestehen
- Die beiden nicht genannten Fixes einspielen – der Snapshot des gesperrten Guthabens (PR #1187) und die Modulkonten-Sperre (Commit 3524ebc)
- Sicherheitskontakt bei Cosmos Labs registrieren – während des Vorfalls stellte sich heraus, dass elf EVM-Deployments nie registriert waren
Warden Protocol entschied sich für einen alternativen Weg: Das Team blockierte die Erstellung von Vesting-Konten vollständig, da diese die einzige Quelle gesperrter Guthaben auf Warden sind und keine Abhängigkeit von benutzergenerierten Vesting-Konten besteht. ZetaChain portierte alle drei Fixes und stellte fest, dass der Cherry-Pick allein den Fork nicht abdeckte, weil dort duplizierte unexportierte Hilfsfunktionen existierten.
Schadensumfang und offene Fragen
Nach Angaben von Cosmos Labs wurden die Angreifer auf sechs Chains aktiv. Auf dezentralen Börsen verkauften sie betroffene Vermögenswerte im Wert von rund 2,87 Millionen US-Dollar (basierend auf Kursen vom 19. August). Auf zentralen Börsen wurden weitere etwa 2,85 Millionen US-Dollar abgesetzt. Die Zahlen wurden von den betroffenen Chains geliefert und nicht unabhängig geprüft. Da das Cosmos-Ökosystem über 115 bekannte öffentliche Blockchains umfasst und das Unternehmen kein vollständiges Register seiner Software-Deployments führt, ist das tatsächliche Ausmaß unklar. Der Vorfall offenbart strukturelle Schwächen in der Sicherheitskommunikation: Weder die verzögerte private Benachrichtigung noch die lückenhafte Dokumentation des Patches sind mit den eigenen Richtlinien vereinbar. Die Frage, warum Cosmos Labs nach der Bestätigung, dass alle Chains betroffen sind, nicht auf einen geschlossenen Verteilungsprozess umschwenkte, bleibt unbeantwortet. Die Hacker News hat Cosmos Labs um Stellungnahme gebeten.
Der Exploit untergräbt das Vertrauen in den Stillen-Patch-Prozess, der für kritische Lücken offenbar nicht ausgelegt ist. Zukünftig müssen Chain-Betreiber darauf bestehen, dass Schwachstellen, die Gelder bedrohen, auch dann privat kommuniziert werden, wenn der Patch bereits öffentlich vorliegt. Die Ereignisse zeigen zudem, dass ein dezentrales Ökosystem ohne zentrale Registrierung und sichere Kommunikationskanäle für Sicherheitsvorfälle anfällig bleibt. Eine koordinierte Reaktion – von der Erkennung über die private Patch-Verteilung bis zur zeitnahen Offenlegung – ist der einzige Weg, um ähnliche Angriffe in Zukunft zu verhindern.
