Drei Stunden, Nicht Drei Monate
Am 23. Juli saßen drei Sicherheitsforscher von Hacktron vor einem Heap-Buffer-Overflow in libheif, der Bibliothek, die HEIC- und HEIF-Fotodateien dekodiert. Sie hatten eine Theorie. OpenAIs eigenes Community-Forum, community.openai.com, lief auf Discourse. Discourses Upload-Pipeline reichte unbekannte Bildformate direkt an ImageMagick weiter, das auf dieselbe verwundbare libheif-Bibliothek setzte. Claude Opus 4.8 verbrachte mehrere Sitzungen damit, aus der Theorie einen funktionierenden Exploit zu machen, und kam nicht an der Address Space Layout Randomization vorbei. Die Forscher legten die Sache zur Seite.
Am Abend des 24. Juli veröffentlichte Anthropic dann Claude Opus 5. Das Team gab dem neuen Modell dasselbe Problem. Innerhalb von drei Stunden hatte es einen funktionierenden ARM64-Exploit für einen lokalen Mac und portierte ihn eigenständig auf Discourses produktive x86-64- und jemalloc-Umgebung. Um 06:00 UTC am 25. Juli funktionierte der Exploit gegen ein lokales Ziel. Um 10:00 UTC funktionierte er gegen OpenAIs lebendes Forum.
Der Fehler, Den Niemand Wirklich Patchen Musste
Die libheif-Lücke war keine Neuentdeckung. Sie war bereits stromaufwärts behoben worden, still, ohne dass ihr eine CVE-Nummer zugewiesen wurde. Keine CVE bedeutete kein Alarm bei Debians Sicherheitsteam, weshalb Debian 12, das Basisabbild von Discourse, den Fix nie übernahm. Discourse erbte die Lücke über ImageMagick. OpenAIs Forum erbte sie über Discourse. Drei Organisationen, drei getrennte Entscheidungen, nichts zu tun, keine davon für sich genommen falsch.
Der Forumseinbruch allein wäre eingedämmt geblieben. Was daraus einen OpenAI-Vorfall machte, war ein Single-Sign-on zwischen dem Forum und den ChatGPT- und Codex-Konten der Mitarbeiter. Die Kompromittierung eines Forumkontos gab den Forschern eine Sitzung, die weiter in Codex führte. Codex war mit GitHub verdrahtet. GitHub hielt das openai/openai-Monorepo. Neun Komponenten, neun getrennte Teams, ein durchgehender Pfad von einer ungepatchten Fotobibliothek bis zum Quellcode.
Wie Schnell Sich Die Kette Tatsächlich Schloss
Hacktron veröffentlichte seine eigene Zeitleiste auf die Minute genau. Nebeneinandergelegt lag zwischen einem Modell, das die Aufgabe nicht schaffte, und einem Modell, das direkt durch OpenAIs Identitätsgrenze ging, genau eine Produktveröffentlichung.
| Zeit (UTC) | Ereignis | Akteur |
|---|---|---|
| 23. Jul, 05:00-06:00 | libheif-Overflow identifiziert; Opus 4.8 scheitert an einem zuverlässigen Exploit | Mensch + Opus 4.8 |
| 24. Jul, Abend | Claude Opus 5 veröffentlicht; erhält dasselbe Ziel | Anthropic |
| 25. Jul, 06:00 | Funktionierender ARM64-Exploit lokal auf einem Mac bestätigt | Opus 5 |
| 25. Jul, 10:00 | Remote-Code-Ausführung auf Discourse Cloud erreicht, /etc/hosts ausgelesen | Opus 5, menschengeführt |
| 25. Jul, 13:30-15:30 | Mitarbeiter-Konto bei ChatGPT und Codex erreicht; Zugriff nachgewiesen, Tests gestoppt | Menschliche Forscher |
| 25. Jul, 22:49 | OpenAI bestätigt einen ausgerollten Fix | OpenAI |
| 1. Sep | OpenAI zahlt 6.500 Dollar Bounty, nur für den SSO-Fund | OpenAI |
Der Drei-Stunden-Exploit ist die Schlagzeile. Der Teil, über den es sich nachzudenken lohnt, sind die 22 Stunden und 49 Minuten zwischen dem Erreichen eines Mitarbeiterkontos und OpenAIs Bestätigung des Fixes. Das war die eigentliche Reaktionszeit, gegen die die Kette getestet wurde. Sie hielt.
Warum Das Für Jeden Betrieb In Der EU Zählt, Nicht Nur Für KI-Labore
Hacktrons eigenes Fazit ist unverblümt: Sicherheit stützte sich lange auf Komplexität als Burggraben, auf die Annahme, dass Exploit-Entwicklung ein gut ausgestattetes Team und Monate an Vorlauf braucht. Genau diesen Burggraben hat Opus 5 bei dieser Lücke beseitigt. Die Forscher schrieben, dass Arbeit, die früher knappe Spezialkräfte brauchte, heute in Rechenleistung übersetzt werden kann. Sie ergänzten, dass der Sprung von Opus 5 zur nächsten Modellgeneration in ihren eigenen Tests bereits sichtbar war.
Für ein Unternehmen unter NIS2, in Deutschland umgesetzt im NIS2UmsuCG, landet diese Verdichtung auf der Uhr, nicht nur im Budget. Wesentliche und wichtige Einrichtungen müssen einen erheblichen Vorfall binnen 24 Stunden nach Kenntnisnahme melden und binnen 72 Stunden einen vollständigen Bericht einreichen. Hacktrons eigene Kette, vom funktionierenden Exploit bis zum kompromittierten internen Repository, schloss sich innerhalb genau dieses 72-Stunden-Fensters. Die Meldeuhr und die Uhr des Angreifers laufen nicht mehr unterschiedlich schnell. Ein Erkennungsprozess, der auf Tage statt Stunden ausgelegt ist, ist für den falschen Gegner gebaut.
Die Essenz
Niemand in dieser Geschichte handelte leichtsinnig. OpenAI betrieb ein Bug-Bounty-Programm und zahlte binnen Tagen aus. Hacktron legte verantwortungsvoll offen und stoppte in dem Moment, in dem der Zugriff nachgewiesen war. Discourse lieferte binnen 48 Stunden nach der Meldung einen Fix. Das System funktionierte genau wie geplant. Ein KI-Modell erreichte trotzdem den Quellcode eines führenden KI-Labors, ausgehend von einer Foto-Upload-Lücke, die anderswo im Internet längst behoben war.
OpenAIs eigene Bounty-Bedingungen schlossen Tests gegen Discourse selbst aus, weshalb die 6.500-Dollar-Zahlung nur den Identitätsgrenz-Fehler abdeckte, nicht den Exploit, der die Forscher überhaupt erst hineinbrachte. Diese Lücke zwischen dem, was ein Bounty-Programm abdeckt, und dem, was ein Angreifer tatsächlich braucht, verdient eine eigene Prüfung, modellgestützt oder nicht.
Weiterlesen: Ihr NIS2-Bedrohungsmodell hat den falschen Angreifer angenommen | Die besten KI-Hacking-Tools sind jetzt nur auf Einladung
