Injective, eine auf dezentrales Finanzwesen (DeFi) zugeschnittene Layer-1-Blockchain, musste seine Netzwerkoperationen nach einem Exploit, der sein Protokoll für Binäroptionen angriff, für etwa vier Stunden aussetzen. Der Vorfall führte zu geschätzten Verlusten in Höhe von 4,9 Millionen US-Dollar.
Der Sicherheitsvorfall wurde zuerst von Nutzer Paddy-earthling auf X offengelegt und machte kritische Versäumnisse im Orakel-Management, in den Fallback-Mechanismen und in der Governance des Protokolls nach dem Vorfall sichtbar.
Mechanik des Angriffs: Ghost Oracles und Edge Cases
Der Exploit nutzte einen deaktivierten, aber weiterhin registrierten Orakel-Feed aus—nicht eine Schwachstelle in der Kryptografie oder in den grundlegenden Konsensmechanismen.
Nutzung eines Zombie-Orakels:
Der Angreifer identifizierte eine veraltete Preis-Orakel-Komponente auf Injective namens Frontrunner. Obwohl die zugrunde liegenden Datenquellen des Orakels schon lange bereinigt waren, blieb der Feed in der Registry der Chain registriert.
Massenerstellung:
Durch die ausnutzbare permissionless Markterstellung des Protokolls schuf der Angreifer 299 Märkte für binäre Optionen, die speziell auf diesen toten Orakel-Feed abgebildet waren.
Auslösen des Refund-Mechanismus:
Da der Frontrunner-Orakel-Feed keine Live-Daten mehr abrufen konnte, konnte das Optionsprotokoll die Settlement-Preise nicht auflösen. Dadurch wurde der integrierte Fallback-Mechanismus für „Keine-Preis-Rückerstattung“ ausgelöst.
Auszahlungs-Verfielfachung:
Ein logischer Fehler in der Refund-Routine erlaubte dem Angreifer, die Zustandsübergänge während der Abwicklung auszunutzen. Anstatt eine standardmäßige 1:1-Rückerstattung für das gesperrte Kapital zu erhalten, zog der Angreifer etwa das 2-Fache der erwarteten Auszahlung über die 299 synthetischen Märkte.
Mittelbewegung und On-Chain-Fußabdruck
Nach dem Exploit wandelte der Angreifer die abgezapften USDC-Reserven in etwa 1.980 ETH um (bewertet auf ungefähr 4,9 Millionen US-Dollar).
Zieladresse:
Die überbrückten Mittel wurden an eine Ethereum-Wallet übertragen, die sich laut Berichterstattung vollständig inaktiv verhält.
Aktueller Status:
Es wurden keine ausgehenden Transaktionen, Tumbler-Routing oder Mischdienste (wie Tornado Cash) von der Empfängeradresse aus initiiert. Es heißt, der Angreifer bewerte White-Hat-Kommunikationen zur Abwicklung.
Bedenken hinsichtlich Protokollreaktion und Transparenz
Obwohl die technische Ursache der Sicherheitslücke schnell behoben wurde, ist das Vorgehen des Teams im Umgang mit dem Vorfall von Sicherheitsforschern und Community-Mitgliedern kritisch beäugt worden.
PR-Stille vs. operative Ausfallzeit:
Während des Netzwerkstillstands von etwa vier Stunden veröffentlichten die offiziellen Social-Channels von Injective weiterhin geplante Werbe- und Marketinginhalte, ohne den Stillstand öffentlich anzusprechen.
Code-Sichtbarkeitsbeschränkungen:
Paddy-earthling wies darauf hin, dass der Kern-Chain-Code von Injective zuvor auf privat gesetzt worden war, die Schwachstelle jedoch durch die Analyse des öffentlich zugänglichen SDK entdeckt wurde. Kritiker argumentieren, dass das Geheimhalten der Kernverträge unabhängige Sicherheitsforscher und White-Hat-Bug-Jäger abschreckt, während es nicht verhindert, dass anspruchsvolle Angreifer Oberflächenfehler im SDK identifizieren.
Umgang mit Governance:
Obwohl die Liquiditätslücke auf Protokoll-Ebene schnell ausgeglichen wurde, wurden Fix und Hot-Patch direkt von Kern-Mitwirkenden umgesetzt—ohne Abstimmung in der On-Chain-Governance oder formelles öffentliches Post-Mortem zum Zeitpunkt der Wiederherstellung des Netzwerks. #Injective🔥 #injective #CryptoSecurity #CryptoNewss #BinanceSquare
vier zentrale Erkenntnisse zum Exploit von Injective bei binären Optionen:
Risiko der Zombie-Registry: Eine deaktivierte Datenquelle ist kein dekommissioniertes Orakel. Wenn ein Feed weiterhin on-chain registriert bleibt, werden permissionless-Tools zur Markterstellung ihn als gültige Infrastruktur behandeln, wodurch die Bereinigung der Registry genauso kritisch ist wie die Pflege aktiven Codes.
Asymmetrisches Risiko in Sicherheitsmechanismen: Fallback-Routinen wie „Keine-Preis-Rückerstattungen“ sind darauf ausgelegt, Kapital zu schützen, aber Logikfehler in ihrer Ausführung können Sicherheitsnetze in Ausnutzungsmechanismen verwandeln. Ein Protokollfehler sollte standardmäßig die Kapitalerhaltung priorisieren—niemals doppelte Auszahlungen.
Die Grenzen geschlossener Repositories: Das Verbergen von Kern-Chain-Code bietet nur einen minimalen Schutz, wenn öffentlich zugängliche SDKs weiterhin systemische Edge Cases abbilden. Undurchsichtigkeit schränkt unabhängige Sicherheitsforscher ein, verhindert aber kaum entschlossene Angreifer.
PR-Ausrichtung vs. Krisenrealität: Das Stoppen einer Blockchain für vier Stunden bei gleichzeitiger Beibehaltung normaler Social-Media-Posts zur Promotion erzeugt eine große Transparenzlücke. In Web3-Sicherheitsereignissen schadet operative Funkstille der Glaubwürdigkeit des Protokolls mehr als der tatsächliche Verlust von Kapital.