BTCVN4 hat ein ungutes Gefühl.
Am 31.8. ereignete sich bei Injective ein Exploit, der einen Schaden von etwa 4,9 Millionen USD verursachte. Zunächst wurde der Vorfall als ein Angriff auf mehrere Binary-Options-Anwendungen im Ökosystem beschrieben.
Allerdings stellt ein Analysebericht vom 3.9. ein noch ernsteres Problem in den Raum:
👉 Die Sicherheitslücke könnte mit den nativen/Core-Modulen von Injective selbst interagiert haben, statt sich nur in einer externen Binary-Options-Anwendung zu befinden.
Und das ist genau der Punkt, den INJ-Holder besonders im Blick haben sollten.
1. Market-ID collision: der Ausgangspunkt des Exploits
Laut On-Chain-Analysen hat der Angreifer einen Fehler ausgenutzt, der mit der Art zusammenhängt, wie Injective Market IDs erzeugt.
Die Market-ID wird aus vielen Feldern von Daten gebildet, wie etwa:
• Oracle type
• Ticker
• Quote denomination
• Oracle symbol
• Oracle provider
Das Problem liegt darin, wie diese Felder zusammengesetzt werden, ohne eine ausreichend klare Trenn-/Längenmechanik.
Das kann theoretisch zu folgender Situation führen:
Zwei unterschiedliche Markt-Konfigurationen → erzeugen dieselbe Market-ID.
Der Angreifer hat diese Möglichkeit genutzt, um Binary-Options-Märkte mit einer besonderen Struktur zu erzeugen, und anschließend mit der Settlement-/Refund-Logik interagiert.
Berichten zufolge hat der Angreifer innerhalb von etwa 19 Stunden rund 299 Märkte erstellt und am Ende etwa 4,9 Millionen USD abgezogen.
2. Aber die größere Frage: Wo steckt der Fehler?
Das ist der bemerkenswerte Teil.
Injective hat bestätigt, dass:
• Der Konsens wurde nicht kompromittiert
• Native INJ ist nicht betroffen
• Gestaktes INJ ist weiterhin sicher
• Der Vorfall betrifft nur einige Anwendungen, die Binary Options verwenden
Das ist eine gute Nachricht für INJ-Holder.
Doch einige unabhängige Analysen sind der Ansicht, dass die Geschichte komplexer ist.
Laut dem Forscher Earthling Paddy hängt der Exploit mit den nativen Exchange- und Insurance-Modulen von Injective zusammen.
Mit anderen Worten:
Binary Options könnte die „Tür“ sein, die der Angreifer nutzt, doch die ausgenutzte Logik liegt tiefer in den Modulen des Protokolls.
Das ist ein extrem wichtiger Unterschied.
Wenn der Fehler nur in einem einzelnen Smart Contract/ einer einzelnen Anwendung liegt → dann ist der Risikoumfang relativ eng begrenzt.
Wenn eine Anwendung jedoch eine falsche Logik innerhalb nativer Protokoll-Module auslösen kann, wird das Problem:
Angriff auf Application-Ebene → aber die Attack Surface liegt auf der Protokoll-Ebene.
🔴 3. Das auffälligste Beweisstück: emergency patch behebt CORE-Logik
Eines der Details, die BTCVN4 am meisten auffallen lässt, ist das Notfall-Upgrade:
v1.20.3-safeharbor.1
Diese Release wurde während der Ereignisbehandlung auf dem Injective Mainnet bereitgestellt.
Laut den Analyseberichten hat das Patch bemerkenswerte Änderungen vorgenommen, wie zum Beispiel:
✅ Zusätzliche Prüfung der Denomination für den Insurance Fund.
✅ Deaktivierung des Binary-Options-Settlements im Mainnet.
Das Bemerkenswerte ist, dass diese Änderungen im Core-Blockchain-Code liegen.
Daher stellt sich eine naheliegende Frage:
Wenn das Problem komplett in einer einzelnen externen Binary-Options-Anwendung liegt, warum musste dann ein emergency patch die Logik auf der Protokoll-/Core-Ebene ändern?
Das ist noch kein Beweis, um zu dem Schluss zu kommen, dass der Injective-Konsens oder natives INJ kompromittiert wurden.
Aber es ist ein starkes Indiz dafür, dass wir die Sache nicht einfach auf „eine externe Anwendung wurde gehackt“ reduzieren sollten.
4. Hat die Chain wirklich „angehalten“ oder war es nur ein emergency upgrade?
Das ist ebenfalls ein Punkt, der gerade diskutiert wird.
Injective beschreibt das Ereignis als ein beschleunigtes Netzwerk-Upgrade und betont gleichzeitig, dass Blockchain und Konsens weiterhin sicher sind.
Allerdings zeigen On-Chain-Daten, die einige Forscher ausgewertet haben, dass es etwa 3 Stunden und 42 Minuten lang keinen neuen Block gab – während die Validatoren eine dringende Notfallaktualisierung ausrollten.
Einige Validatoren wurden sogar in den Jail gesetzt, weil sie das Upgrade nicht innerhalb der geforderten Zeit abgeschlossen haben.
Daher gibt es technisch gesehen einen Unterschied zwischen:
„Konsens wurde kompromittiert“ und „Blockproduktion wurde unterbrochen, um ein emergency patch einzusetzen“.
Diese beiden Dinge sind nicht dasselbe.
Zurzeit sprechen die Daten dafür, dass der Konsens nicht vom Angreifer übernommen wurde, aber das Netzwerk hat während der Reaktion auf den Vorfall eine erhebliche Unterbrechung erlebt.
5. Was WISSEN wir also schon?
Zum jetzigen Zeitpunkt sind einige Punkte relativ klar:
1️⃣ Rund 4,9 Millionen USD wurden ausgenutzt (exploit).
2️⃣ Der Angreifer hat die Market-ID collision in der Settlement-Logik von Binary Options genutzt.
3️⃣ Etwa 1.980 ETH sollen nach Ethereum übertragen worden sein und liegen laut veröffentlichten Berichten weiterhin an der betreffenden Adresse für den Vorfall.
4️⃣ Injective hat ein emergency release v1.20.3-safeharbor.1 bereitgestellt.
5️⃣ Die Settlement-Logik für Binary Options wurde auf dem Mainnet deaktiviert.
6️⃣ Die Insurance-Fund-Logik wurde um eine Prüfung der Stückelung (Denomination) ergänzt.
7️⃣ Injective bestätigt, dass der Konsens sowie native INJ und gestaktes Vermögen nicht kompromittiert wurden.
Diese Punkte zeigen, dass das Exploit relativ schnell eingedämmt wurde und sich der Schaden nicht zu einem Angriff auf die Konsensschicht ausgeweitet hat.
6. Aber was ist bislang NOCH NICHT geklärt?
Das ist der Teil, den BTCVN4 für INJ-Holder als besonders genau zu beobachten hält.
❓ Was genau ist der exakte Attack Path?
❓ Mit welchen Modulen hat die Market-ID collision interagiert?
❓ Warum muss ein Fehler, der bei Binary Options beginnt, die Logik im Core-Protokoll betreffen?
❓ Wie hoch ist der endgültige Gesamtschaden?
❓ Wer trägt tatsächlich den Shortfall von rund 4,9 Millionen USD?
❓ Wurden die ausgenutzten Gelder zurückgeholt oder nicht?
❓ Gibt es weitere Varianten derselben Schwachstellenklasse?
❓ Gibt es weitere native Module, die eine ähnliche Market-ID-Logik verwenden und daher erneut auditiert werden müssen?
Und vor allem:
Hat Injective die gesamte Attack Surface der nativen Module geprüft oder nur den Binary-Options-Vektor gesperrt?
Ein vollständiges technisches Post-Mortem ist entscheidend, um diese Fragen zu beantworten.
Aktuelle Berichte besagen, dass Injective noch kein vollständiges technisches Post-Mortem veröffentlicht hat, das den gesamten Ausführungspfad (execution path) sowie die Verteilung der Schäden beschreibt.
7. Wie sollten INJ-Holder diese Sache verstehen?
Meiner Meinung nach sollten wir noch nicht zu dem Schluss kommen, dass Injective „core compromise“ erlitten hat.
Denn aktuell gibt es noch keinen Beleg dafür, dass:
Der Konsens vom Angreifer kontrolliert wurde.
Native INJ wurde unrechtmäßig gemintet.
Gestaktes INJ wurde gestohlen.
Der Validator Set wurde vom Angreifer übernommen.
Aber gleichzeitig sollte man den Vorfall auch nicht kleinreden.
Denn wenn Berichte über einen Market-ID-Collision-Fehler und die Interaktion mit dem Core-Modul im Post-Mortem bestätigt werden, dann ist die Sache an sich deutlich ernster, als wäre nur ein fehlerhafter Smart Contract für Binary Options betroffen.
Das wird zeigen:
Eine Anwendung kann eine gefährliche Logik innerhalb nativer Protokoll-Module auslösen.
Das ist ein Problem der Protokoll-Sicherheitsarchitektur, nicht einfach nur ein Fehler eines einzelnen dApp.
BLICKWINKEL VON BTCVN4
Ich denke, dass es derzeit zwei Ebenen an Informationen gibt, die getrennt werden müssen:
Schicht 1 – Gute Nachricht:
Injective hat die Ausnutzung (Containment) eingedämmt; nach den derzeit verfügbaren Informationen wurde der Konsens nicht kompromittiert, und natives INJ sowie das Staking sind weiterhin geschützt.
Schicht 2 – Risiken, die es zu beobachten gilt:
Wenn eine Market-ID-Collision tatsächlich aus native Exchange-/Insurance-Module stammt oder diese beeinflussen kann, dann müssen wir wissen, wie groß der Umfang dieser Schwachstellenklasse ist.
Das ist erst die entscheidende Größe dafür, wie hoch das langfristige Risiko für INJ ist.
Daher meine ich:
👉 Verbreitet kein FUD, dass INJ gebrochen/zerstört wurde.
Aber auch:
👉 Zieht nicht vorschnell den Schluss „nur Binary Options, also irrelevant fürs Protokoll“.
Beide Extreme liegen falsch.
Das Wichtigste, worauf man jetzt am meisten hoffen sollte, ist nicht ein beruhigender Tweet für den Markt.
Sondern:
EIN VOLLSTÄNDIGES TECHNISCHES POST-MORTEM.
Wenn ein Post-Mortem belegt, dass die Schwachstelle ausschließlich auf Binary Options begrenzt ist und die dazugehörigen Module vollständig auditiert wurden → dann sinkt das Risiko deutlich.
Im Gegenteil: Wenn Market-ID collision oder eine ähnliche Logik in mehreren anderen nativen Modulen gefunden wird → dann könnte das zu einem großen Problem für die langfristige Thesis von INJ werden.
INJ-Holder sollten in den nächsten Tagen besonders auf 4 Dinge achten:
Technisches offizielles Post-Mortem.
Wurde zusätzlich noch eine Schwachstelle in nativen Exchange-/Insurance-Modulen gefunden?
Wurde der Betrag von ~4,9 Mio. USD zurückgeholt oder liegt er weiterhin in der Wallet des Angreifers?
Funktionieren die Validatoren, die Exchange und das Injective-Ökosystem wieder vollständig normal?
Noch ist es nicht an der Zeit, in Panik zu geraten. Aber definitiv ist jetzt der Moment, die Wachsamkeit zu erhöhen.
BTCVN4 wünscht viel Glück
