IT-Sicherheit · Bug Bounty
Weniger als 72 Stunden bis ins interne Repository: Was der Modellwechsel mitten im Angriff auf OpenAI zeigt
Die Firma Hacktron AI hat beschrieben, wie ihr Team in weniger als 72 Stunden von einem öffentlichen Diskussionsforum bis in ein internes Code-Repository von OpenAI gelangt ist. Das Wall Street Journal berichtete am Donnerstagabend zuerst darüber, TechCrunch und The Verge zogen am Freitag nach. Der technische Bericht der Forscher selbst ist allerdings schon vom 13. September — wir haben ihn im Volltext gelesen, und er enthält mehrere Angaben, die in den Aufgriffen fehlen.
Zunächst der Weg. Einstiegspunkt war community.openai.com, OpenAIs öffentliches Forum auf Basis der Software Discourse. Wer dort ein Bild im HEIF-Format hochlädt, dessen Datei wird an ImageMagick zur Umwandlung weitergereicht — und damit an die darunterliegende Bibliothek libheif. Debian 13 lieferte zu diesem Zeitpunkt noch die verwundbare Version 1.19.8 aus, weil Sicherheitskorrekturen nicht zurückportiert worden waren. Über einen Heap-Pufferüberlauf in diesem Parser erlangte das Team Codeausführung und administrativen Zugriff auf die Forenumgebung. Zusammen mit einer zweiten Schwachstelle — einer Fehlkonfiguration in OpenAIs Single-Sign-on-Infrastruktur — ließen sich daraus die ChatGPT- und Codex-Konten mehrerer OpenAI-Mitarbeiter übernehmen.
Der letzte Schritt ist der, über den man in der eigenen Organisation nachdenken sollte. Das Codex-Konto eines Mitarbeiters war mit OpenAIs GitHub-Organisation verbunden. Die Forscher öffneten darüber einen Pull Request (Nummer 1186742) im internen Monorepo openai/openai — ausdrücklich als harmloser Nachweis, ohne sich selbst sensible Inhalte anzusehen. Der Bericht benennt den Umfang des theoretisch Erreichbaren nüchtern: GitHub, Slack und E-Mail. Der Coding-Agent war hier kein Werkzeug des Angreifers, sondern der Zugang selbst: Er trug die Rechte seines Nutzers, und wer das Konto hat, hat den Agenten.
Die Zeitleiste ist knapp. Am 25. Juli 2026 zwischen 05:00 und 06:00 UTC gelang die Codeausführung samt Administratorzugriff auf das Forum, zwischen 08:00 und 10:00 UTC ging die Meldung über Bugcrowd bei OpenAI ein, zwischen 13:30 und 15:30 UTC folgte der Zugriff auf das Mitarbeiterkonto und der Nachweis. Discourse veröffentlichte am 28. Juli einen Fix samt Advisory, Debian lieferte sein Sicherheitsupdate am 8. August nach.
Nun der Teil, der die Meldung interessant macht. Am 24. Juli hatten die Forscher mit Claude Opus 4.8 einen funktionierenden Exploit gebaut — allerdings nur mit abgeschalteter Speicherverwürfelung (ASLR), einem Standardschutz, der Angreifern die Adressen im Speicher verbirgt. Gegen die tatsächliche Discourse-Konfiguration mit aktiviertem ASLR scheiterten mehrere Sitzungen. Am Abend desselben Tages veröffentlichte Anthropic Claude Opus 5. Die Forscher starteten eine neue Sitzung; binnen drei Stunden lag ein funktionierender ARM64-Exploit vor. Ihre eigene Formulierung: „Opus 4.8 struggled across several sessions to produce a working exploit with ASLR enabled. Within hours of Opus 5's release, we gave it the same problem and it succeeded.“
Eine Präzisierung, die im deutschsprachigen Aufgriff verloren ging: Mehrere Meldungen nennen allein „Claude Opus 4.8“ als das Modell, mit dem der Einbruch gelang. Das ist nach der Aktenlage falsch herum. Opus 4.8 scheiterte an genau der Hürde, die zählte; erfolgreich war Opus 5. Wer die Meldung als Beleg für die Fähigkeiten eines bestimmten Modells liest, liest sie sonst am entscheidenden Punkt verkehrt. TechCrunch ergänzt eine Randnotiz mit eigener Brisanz: Opus 5, die Version, die es schaffte, unterliegt keinen sicherheitsbedingten Exportbeschränkungen — anders als das neuere Mythos 5.
War das nun ein autorisierter Test? Hier lohnt der Blick in den Originalbericht, denn die Antwort ist nicht das schlichte Ja, das die Aufgriffe nahelegen. OpenAI zahlte am 1. September eine Prämie von 6.500 Dollar und markierte den Fall als erledigt — verbunden mit einer ausdrücklichen Klarstellung, die Hacktron selbst abdruckt: Tests gegen das bei Discourse gehostete community.openai.com seien vom Bug-Bounty-Programm explizit ausgenommen gewesen; die Prämie würdige den Fund auf OpenAI-Seite, nicht das Vorgehen gegen Discourse. Der Einstiegspunkt lag also außerhalb des freigegebenen Rahmens. Das ändert nichts an der Offenlegung nach den Regeln, aber es macht aus „autorisierter Penetrationstest“ eine ungenauere Beschreibung, als sie klingt.
Was davon in die eigene Planung gehört. Drei Dinge. Erstens: Die Schwachstelle saß nicht im KI-Produkt, sondern in einer Bildbibliothek unter einer Standard-Forensoftware am Rand der eigenen Infrastruktur — ein Nebenschauplatz, über den die Kette dann ins Zentrum lief. Zweitens: Ein Coding-Agent mit Anbindung an die Code-Verwaltung erbt die Rechte seines Nutzers vollständig; die Frage, welche Agenten in Ihrer Organisation an welchen Repositories hängen, ist damit eine Zugriffsfrage und keine Werkzeugfrage. Drittens, und das ist die unbequemste Beobachtung: Die Forscher halten ausdrücklich fest, dass jedes neue Modell dabei fähiger wird. Zwischen „geht nicht“ und „geht in drei Stunden“ lag in diesem Fall ein einziger Modellwechsel über Nacht — ohne dass sich an der Schwachstelle selbst irgendetwas geändert hätte. Für die Risikobewertung heißt das, dass die Haltbarkeit eines „praktisch nicht ausnutzbar“ an den Veröffentlichungszyklus der Anbieter gekoppelt ist.
OpenAI erklärte, man danke den Forschern, habe die Berechtigungen der Anmelde-Token des Forums eingeschränkt und betroffene Token und Sitzungen widerrufen. Eine Stellungnahme von Anthropic zu dem Vorgang war bis Redaktionsschluss nicht auffindbar.
- Hacktron AI — Hacking OpenAI (Primärquelle, 13.9.2026, Volltext selbst gelesen; Autoren Harsh Jaiswal, Mohan Pedhapati, Rahul Maini)
- TechCrunch — Researchers used Anthropic's Claude to hack into OpenAI (18.9.2026)
- The Verge — Security researchers used Claude to help them hack into OpenAI (18.9.2026)