Ostium verliert 23,75 Mio. $ durch Oracle-Signer-Kompromittierung auf Arbitrum

23,75 Millionen Dollar aus einem einzigen Liquiditätsvault, in acht Transaktionen abgezogen, über ein Vertragspaar geleitet, an eine einzige Wallet ausgezahlt. Das ist das Bild des Ostium-Angriffs vom 15. Juli 2026 – und das unangenehme Detail für jedes DeFi-Team, das dies liest: Die Smart Contracts verhielten sich exakt wie spezifiziert. Der Fehler lag eine Ebene höher, in der Off-Chain-Oracle-Infrastruktur und bei den Menschen, die deren Schlüssel halten.

Der Handel auf der Arbitrum-basierten Perps-Plattform ist zum Zeitpunkt dieser Veröffentlichung noch eingefroren. Ostium verspricht mindestens 24 Stunden Vorankündigung, bevor der Betrieb wieder aufgenommen wird. Trader-Sicherheiten und offene Positionen blieben unangetastet. Der gesamte Verlust traf die Liquiditätsanbieter.

Was geschah

Am 15. Juli begann ein Angreifer, der über zwei Sätze gültiger Zugangsdaten verfügte – einen für einen autorisierten Oracle-Signer und einen für einen registrierten PriceUpKeep-Forwarder (die Keeper-Rolle) – kryptografisch gültige, aber inhaltlich betrügerische Preismeldungen in Ostiums Oracle-Pipeline einzuspeisen. Wie Rescana dokumentierte, prüfte die Verifizierungslogik des Oracles lediglich, ob der Signer auf der autorisierten Liste stand – und nichts weiter. Es wurde nicht geprüft, ob der gemeldete Preis innerhalb eines realistischen Rahmens lag.

Mit diesem einfachen Werkzeug waren die Abläufe denkbar simpel. Der Angreifer eröffnete große gehebelte Positionen, manipulierte den Oracle-Preis mit einem signierten Bericht und schloss die Positionen gegen den manipulierten Feed. Das Ganze wurde acht Mal über dasselbe Vertragspaar wiederholt, alle Auszahlungen landeten bei 0x321Df1...8bfD9. Die größte Einzelauszahlung wurde als atomarer Batch ausgeführt, der Öffnungs- und Schließzyklen innerhalb einer einzigen Transaktion kombinierte – effizientes Diebstahlsengineering: kein Zeitfenster, in dem ein Keeper den Vorgang bemerken könnte.

Nachdem der Ostium Liquidity Pool (OLP) Vault geleert war, konvertierte der Angreifer den gestohlenen USDC in 12.080 ETH und schleuste 10.540 davon in TornadoCash. Zum Zeitpunkt der Quellenberichterstattung verbleiben etwa 1.540 ETH ungemischt – eine nachverfolgbare Spur: Wenn dieser Rest liegen bleibt oder zu einer CEX bewegt wird, haben Chain-Analytics-Unternehmen etwas, womit sie arbeiten können.

Ostium pausierte den Handel innerhalb von 60 Minuten nach der ersten Exploit-Transaktion, informierte die Community am 16. Juli und beauftragte Incident-Response- und Strafverfolgungsbehörden. Galaxy Research veröffentlichte am 17. Juli eine technische Analyse. Die Quelle gibt nicht preis, wie die beiden Zugangsdaten kompromittiert wurden – was bedeutsam ist, da Zugangsdatendiebstahl durch Phishing, einen Insider oder eine kompromittierte Signing-Maschine sehr unterschiedliche Lösungsansätze erfordern.

Technische Analyse

Das Ostium-Oracle ist ein klassisches Hybrid-Design: Off-Chain-Worker rufen Preisdaten ab und signieren sie, ein On-Chain-Forwarder (PriceUpKeep) übermittelt sie, und die Perps-Engine verwendet sie als verlässliche Grundlage. Die Signaturprüfung beantwortet exakt eine Frage: „Wurde dies von einem Schlüssel signiert, dem wir vertrauen?" Sie beantwortet nicht: „Ist dieser Preis plausibel?", „Ist dieser Preis aktuell?" oder „Stimmt dieser Preis mit einem zweiten unabhängigen Feed überein?"

Zum Vergleich: Chainlink strukturiert seine Data Feeds so, dass mehrere unabhängige Node-Betreiber Berichte einreichen und der On-Chain-Aggregator einen Median bildet, bevor der Wert den Konsumenten zugänglich gemacht wird (siehe die Chainlink-Dokumentation). Ein einzelner kompromittierter Signer in einem m-of-n-Aggregator kann den Median nur in einem begrenzten Rahmen verschieben, und nur wenn die anderen Betreiber schweigen oder langsam sind. Ostiums Design kollabierte diese m-of-n-Eigenschaft für die Zwecke dieses Angriffs auf effektiv 1-von-1: Eine einzige gültige Signatur reichte als Autorität aus.

Die Kompromittierung des Keepers verschlimmerte die Lage. Ein signierter, aber veralteter oder weit außerhalb des Normbereichs liegender Bericht sollte auf der Forwarder-Ebene herausgefiltert werden können – doch wenn der Angreifer auch den registrierten Keeper kontrolliert, wird der Forwarder zum Komplizen. Deshalb liefen alle acht Transaktionen über dasselbe Vertragspaar, ohne dass ein Circuit Breaker auslöste.

Was nicht versagt hat, verdient Erwähnung. Keine Malware. Kein Smart-Contract-Bug. Kein Re-Entrancy, kein zu einem neuartigen Exploit verdrehtes Flashloan-Primitiv, kein Bridge-Exploit. Die Handelslogik wurde korrekt gegen die empfangenen Eingaben ausgeführt. Das ordnet den Vorfall in dieselbe Kategorie wie die historische Welle von Preisfeed-Manipulationsangriffen gegen unterbesicherte Perps-Plattformen ein – außer dass der Manipulationsvektor hier signierte Zugangsdaten statt eines dünnen Spotmarkts waren. Ich würde argumentieren, dass dies die schwierigere Variante des Problems ist, weil die Signaturvalidität binär ist und der On-Chain-Code keinen natürlichen Vergleichswert hat. Die Grenze der Erkennbarkeit wird durch die Plausibilitätsprüfungen gesetzt, die oberhalb der Signaturprüfung existieren – und bei Ostium war diese Grenze null.

Wer den Schaden trägt

Ostiums Liquiditätsanbieter tragen den gesamten Verlust von 23,75 Millionen Dollar. Das ist der primäre Schaden. Ob sie vollständig entschädigt werden, hängt von Treasury-Reserven und Versicherungsvereinbarungen ab, die die Quelle nicht offenlegt – das ist die größte offene Frage für die nächsten 90 Tage. Wenn Ostium den Verlust auf die LPs sozialisiert, ist mit einem starken TVL-Rückgang bei Wiederaufnahme des Handels zu rechnen. Wenn der Verlust aus dem Treasury oder einem Versicherungsfonds aufgefangen wird, ist ein langsamer Abzug von LPs und eine Neubewertung der von LPs verlangten Gebühren zu erwarten.

Der sekundäre Schaden trifft jede Perps-DEX, die ein Oracle-Design mit einem einzelnen Signer betreibt. Prüfer werden gezielte Fragen zur Verwahrung von Signer-Schlüsseln, zur HSM-Nutzung, zur Trennung der Keeper-Rolle und zu Preisplausibilitätsprüfungen stellen. Teams, die diese Fragen mit „unsere Signer laufen auf einem vertrauenswürdigen Server" beantwortet haben, müssen nun mit Architekturdiagrammen antworten. Versicherungsunternehmen, die DeFi-Protokolle absichern, werden dieselbe Rechnung aufmachen und Prämien entsprechend anpassen.

Arbitrum selbst ist hier ein unbeteiligter Beobachter (dies war kein L2-Problem), aber die Plattform ist relevant für strafrechtliche Folgemaßnahmen. Die 10.540 ETH in TornadoCash sind das entscheidende Geldwäschefaktum. Die Quelle weist auf die häufige Verwendung von Mixern durch finanziell motivierte Akteure hin, einschließlich nordkoreanischer Gruppen, betont aber ausdrücklich, dass keine direkte Zuschreibung zu einer bekannten Gruppe vorliegt. Die verbleibenden rund 1.540 ETH sind die nachprüfbare Spur: Wenn sie in den nächsten 30 Tagen einen sanktionierten Mixer oder eine KYC-Börse betreten, sollten wir entweder eine OFAC-Mitteilung oder eine Börseneinfrierungsbenachrichtigung mit Verweis auf die Wallet 0x321Df1...8bfD9 sehen.

Trader mit offenen Positionen bei Ostium zum Zeitpunkt des Angriffs kamen am besten weg, soweit das bei einem Hack dieser Größenordnung möglich ist: Ihre Sicherheiten blieben erhalten, sie können nur so lange nicht handeln, bis die Infrastruktur gesichert ist. Prognose: Wenn Ostium wieder öffnet, ist mit einer messbaren Spread-Ausweitung und einem OLP-APR-Anstieg zu rechnen, da der Markt die neue Risikoprämie einpreist.

Handlungsempfehlungen für Krypto und DeFi

Für alle, die ein hybrides On-Chain/Off-Chain-Oracle betreiben oder darauf aufbauen, sind die Hausaufgaben dieser Woche konkret.

Erstens: Die Annahme der reinen Signaturprüfung auditieren. Wenn Ihr On-Chain-Oracle-Consumer einem einzelnen Signer vertraut, behandeln Sie das als aktive Schwachstelle. Fügen Sie Preisplausibilitätsgrenzen hinzu (maximale Abweichung vom letzten akzeptierten Preis, maximale Abweichung von einem sekundären Feed, Aktualitätsprüfungen gegen Block-Timestamps). Nichts davon ist exotisch, und jede dieser Maßnahmen hätte den Ostium-Angriff abgemildert.

Zweitens: Die Signer-Rolle von der Keeper-Rolle auf Zugangsdatenebene trennen. Wenn eine Maschine oder ein Betreiber beide hält, gibt ein einziger Kompromiss dem Angreifer vollständige End-to-End-Kontrolle. Die Quelle weist ausdrücklich darauf hin, dass beide Rollen bei Ostium nur durch Governance vergeben werden sollen und nicht selbst zuweisbar sind – was bedeutet, dass die Kompromittierung von außerhalb des Zuweisungsprozesses kam, höchstwahrscheinlich durch Zugangsdatendiebstahl.

Drittens: Pro-Block- und Pro-Fenster-Auszahlungsobergrenzen für LP-Vaults einführen. Acht Transaktionen bis zur vollständigen Leerung eines Vaults sind ein Symptom fehlender Ratenbegrenzung bei Auszahlungen relativ zur Vault-Größe. Eine Obergrenze, die den Vault automatisch pausiert, wenn Abflüsse beispielsweise 5 Prozent des TVL in einem gleitenden Fenster überschreiten, hätte dem Incident-Response-Team eine Stunde echten Handlungsspielraum verschafft, statt einer 60-minütigen nachträglichen Pause.

Viertens: Die Pause einüben. Ostiums 60-minütige Reaktion ist nach Branchennormen akzeptabel, aber nicht schnell genug, um bei aktivem atomaren Batching etwas zu bewirken. Teams sollten die Zeit bis zur Pause ab der ersten anomalen Transaktion messen, nicht ab der menschlichen Benachrichtigung. Für Referenzen zu On-Chain-Circuit-Breaker-Mustern decken die Ethereum-Entwicklerdokumentationen die Grundbausteine ab; der schwierige Teil ist die Verknüpfung mit einem Anomalie-Detektor, nicht das Schreiben der Pause-Funktion.

Wichtigste Erkenntnisse

• 23,75 Millionen Dollar verließen Ostiums OLP-Vault am 15. Juli 2026 in acht Transaktionen, alle an eine einzige Wallet ausgezahlt, ohne dass ein Smart-Contract-Bug beteiligt war.
• Die Grundursache war ein Oracle, das die Signer-Identität, nicht aber die Preisplausibilität validierte, kombiniert mit einer Kompromittierung sowohl der Signer- als auch der Keeper-Zugangsdaten.
• 10.540 der 12.080 gestohlenen ETH flossen in TornadoCash; die verbleibenden rund 1.540 ETH sind die nachprüfbare Spur für die Zuordnung in den nächsten 30 Tagen.
• Offene Frage mit einer harten Grenze: Die Quelle gibt nicht preis, wie die beiden Zugangsdaten entwendet wurden. Solange Ostium kein Post-Mortem veröffentlicht, das den Vektor benennt (Phishing, Insider, kompromittierte Signing-Infrastruktur), können andere Perps-DEXes nicht wissen, ob sie derselben Gefährdung ausgesetzt sind.
• Prognose: Wenn Ostium wieder öffnet, sollte der OLP-APR innerhalb der ersten Woche sichtbar nach oben angepasst werden, um LPs für das neu sichtbar gewordene Oracle-Risiko zu entschädigen. Geschieht das nicht, preist der Markt dies nicht korrekt ein.