Cosmos Labs hat eingeräumt, dass eine Schwachstelle, die das Unternehmen zuvor geprüft und freigegeben hatte, später mit einem Exploit über sechs Chains in Verbindung gebracht wurde, der 5,7 Millionen US-Dollar an Verlusten verursachte – ein Bewertungsfehler, der zu einem sicherheitsrelevanten Vorfall über mehrere Netzwerke hinweg wurde.

Was laut Cosmos Labs schiefging

Laut dem Post-mortem des Projekts war die dem Vorfall zugrunde liegende Schwachstelle bewertet und vor ihrer Ausnutzung versehentlich freigegeben worden. Das heißt: Der Fehler war intern erkannt, aber nicht als ausnutzbar eingestuft worden.

Da der Fehler freigegeben statt behoben wurde, war vor dem Exploit kein Fix verfügbar, und der Angreifer konnte eine Schwachstelle ausnutzen, die dem Team bereits bekannt, aber herabgestuft worden war. Der offengelegte Verlust belief sich auf 5,7 Millionen US-Dollar, wie The Block berichtete.

Das Versagen ist ein Zusammenbruch des Sicherheitsprozesses, kein Produktproblem: Die Lücke liegt zwischen der Bewertung des Fehlers während der Überprüfung und seinem Verhalten nach dem Einsatz in einer live laufenden Cosmos-EVM-Umgebung. Das Fehleinschätzen des Schweregrads bei der Bewertung ist ein bekanntes Versagensmuster in Sicherheitsprogrammen allgemein: Schwachstellen, die in der Überprüfung als risikoarm oder unerreichbar gelten, können sich in der Produktion als ausnutzbar erweisen, sobald ein Angreifer einen Weg findet, den die Bewertung übersah.

Wie der Hack auf sechs Chains den Schaden vergrößerte

Der Exploit blieb nicht auf ein einziges Netzwerk beschränkt. Da der Fehler in einem gemeinsam genutzten Cosmos-EVM-Modul steckte, trat dieselbe zugrunde liegende Schwachstelle auf sechs Chains erneut auf, die den betroffenen Code übernommen hatten – was den Vorfall von einem Single-Chain-Bug zu einem systemischen Ereignis machte.

Dieses Muster gemeinsamer Abhängigkeiten ist dasselbe, das Cosmos Labs zuvor dazu veranlasste, EVM-Chains nach einem Shared-Bug, der drei Netzwerke leerte, zum Anhalten aufzurufen – ein Beleg dafür, wie ein gemeinsames Modul einen ausnutzbaren Defekt in wiederholte Auswirkungen auf jede Chain verwandelt, die es einsetzt.

Für das vernetzte, auf Cosmos basierende DeFi bedeutet das: Die Angriffsfläche wächst mit der Wiederverwendung von Code. Jede Chain, die das verwundbare Modul importierte, wurde zum Ziel – das vervielfachte sowohl die Verluste in Dollar als auch den operativen Bereinigungsaufwand bei Teams, die den fehlerhaften Code selbst nie geschrieben hatten. Dieses Ansteckungsrisiko durch gemeinsame Abhängigkeiten ist ein Grund, warum ökosystemweite Koordinationsmechanismen – koordinierte Offenlegungen, gemeinsame Sicherheitsadvisories sowie die Fähigkeit, schnell Patches auszurollen oder Chains anzuhalten – in Multi-Chain-Umgebungen mit gemeinsamen Codebasen zum Standard geworden sind.

Was der Vorfall für Audits, Behebung und das Nutzerrisiko bedeutet

Eines der betroffenen Netzwerke, MANTRA, stoppte seine Chain und veröffentlichte gemäß eigener Offenlegung ein vollständiges Incident-Post-mortem mit Details zur Reaktion. Das spiegelt den Notstopp wider, den MANTRA nach dem Cosmos-EVM-Modulproblem anwandte.

Die zentrale offene Frage ist, warum ein intern identifizierter Fehler auf „freigegeben“ herabgestuft wurde und welche Änderungen an Prüf- und Monitoring-Prozessen bei Cosmos Labs eine ähnliche Fehlklassifizierung künftig vor dem Deployment erkennen würden – statt erst, nachdem Gelder bewegt wurden. Zu beobachten bleibt, ob die Prozessänderungen aus dem Post-mortem – und eventuelle Folge-Patches auf den betroffenen Chains – schnell genug umgesetzt werden, um das Vertrauen in die Sicherheit gemeinsamer Module wiederherzustellen, und ob Integratoren ihre eigenen Abhängigkeiten vom betroffenen Code überprüfen.

Für Integratoren und Nutzer besteht das praktische Risiko darin, dass eine Audit-Freigabe nicht dasselbe ist wie Sicherheit in der realen Welt: Chains, die auf gemeinsame Module setzen, erben sowohl den Code als auch dessen ungepatchtes Risiko – Monitoring und die Fähigkeit zum schnellen Anhalten sind daher ebenso wichtig wie die Überprüfung vor dem Launch, die die Schwachstelle übersah.