Quavon Development
AI Security / AI-assisted Exploitation4 Min. Lesezeit

Hacktron nutzte Claude für eine Exploit-Kette bis in OpenAIs internes Repository

Hacktron AI nutzte Claude Opus 5 bei einer realen Bug-Bounty-Untersuchung gegen OpenAI. Aus einer Discourse-RCE und einer SSO-Schwäche entstand Zugriff auf Mitarbeiterkonten und über Codex die Möglichkeit, einen Proof-of-Concept-Pull-Request gegen OpenAIs internes Repository anzulegen.

Redaktion von Quavon DevelopmentVeröffentlicht
Die kurze Antwort

Hacktron AI kombinierte im Rahmen von OpenAIs Bug-Bounty-Programm eine Remote-Code-Execution-Schwachstelle im Discourse-Forum mit einer SSO-Schwäche. Claude Opus 5 half laut Hacktron bei der Entwicklung eines funktionierenden Exploits. Über kompromittierte Mitarbeiterkonten und ein verbundenes Codex-Konto konnte das Team schließlich einen harmlosen Pull Request gegen OpenAIs internes Repository anlegen.

Hacktron AI hat einen Angriff auf OpenAIs Infrastruktur offengelegt, bei dem Claude einen wesentlichen Teil der Exploit-Entwicklung übernahm. Die drei Forscher arbeiteten im Rahmen von OpenAIs Bug-Bounty-Programm. Der Angriff fand Ende Juli statt und wurde im September öffentlich dokumentiert.

Die Kette begann bei OpenAIs Community-Forum, das auf Discourse lief. Hacktron identifizierte einen Speicherfehler in der Verarbeitung von HEIF-Bildern über eine verwundbare libheif-Version. Nach Angaben des Teams gelang es Claude Opus 5, daraus einen funktionierenden Exploit für die reale Umgebung zu entwickeln.

Der Zugriff auf den Forum-Server war aber nur der erste Schritt. Eine zweite Schwäche in OpenAIs Single-Sign-on- und Account-Verknüpfung machte aus der Server-Kompromittierung Zugriff auf ChatGPT- und Codex-Konten von OpenAI-Mitarbeitern. Über ein Codex-Konto, das mit OpenAIs GitHub-Organisation verbunden war, konnte das Team schließlich einen harmlosen Proof-of-Concept-Pull-Request gegen OpenAIs internes Repository anlegen.

Hacktron beendete den Test an diesem Punkt und meldete die Schwachstellen. OpenAI bestätigte die Behebung und zahlte nach Angaben der Forscher 6.500 US-Dollar Bug Bounty.

Der AI-Anteil lag in der Exploit-Entwicklung

Der Fall ist nur dann ein AI-Security-Thema, wenn man sauber trennt, was Claude tatsächlich verändert hat.

Die Schwachstellen selbst waren klassische Software- und Identity-Probleme. Ein fehlerhafter nativer Parser erzeugte die erste Code-Ausführung. Danach vergrößerte eine SSO-Konfiguration den erreichbaren Trust-Bereich.

Claude ersetzte diese Schwachstellen nicht. Das Modell senkte aber den Aufwand, aus dem Speicherfehler einen praktisch funktionierenden Exploit zu bauen.

Hacktron berichtet, dass eine zuvor verwendete Version von Claude Opus 4.8 über mehrere Sessions keinen stabilen Exploit für die geschützte Zielumgebung erzeugen konnte. Kurz nach der Veröffentlichung von Opus 5 stellte das Team demselben Modelltyp das Problem erneut. Laut Hacktron entstand innerhalb weniger Stunden ein funktionierender ARM64-Exploit.

TechCrunch hat diese Darstellung unabhängig aufgegriffen. OpenAI bestätigte gegenüber Medien, dass die gemeldeten Probleme behoben wurden.

Das ist technisch interessanter als die pauschale Aussage, ein Forscher habe „Claude zum Hacken benutzt“. Der relevante Unterschied liegt darin, dass eine Aufgabe, die zuvor über mehrere Agenten-Sessions nicht gelöst wurde, mit einer leistungsfähigeren Modellgeneration in derselben Angriffskette praktisch ausführbar wurde.

Aus Forum-Zugriff wurde Identitätszugriff

Nach der Remote Code Execution auf dem Discourse-System prüfte Hacktron, welche Vertrauensbeziehungen vom kompromittierten Forum aus erreichbar waren.

Dabei fand das Team eine Schwäche in OpenAIs Account- und SSO-Verknüpfung. Nach der veröffentlichten Darstellung konnten die Forscher Session- beziehungsweise Identitätsinformationen so nutzen, dass sie ChatGPT- und Codex-Konten von Mitarbeitern übernahmen.

Mindestens eines dieser Codex-Konten war mit OpenAIs GitHub-Organisation verbunden.

Das zeigt den wichtigeren Architekturfehler der Kette: Ein öffentlich erreichbares Community-System befand sich nicht nur neben internen Identitäten. Seine Kompromittierung ließ sich über eine zweite Vertrauensbeziehung bis zu einem Entwicklerwerkzeug erweitern, das seinerseits Schreibaktionen gegen ein internes Repository ausführen konnte.

Der Proof-of-Concept-Pull-Request war nach Hacktrons Angaben absichtlich harmlos. Das Team sagt außerdem, es habe keinen proprietären Quellcode gelesen und andere erreichbare Dienste nicht weiter untersucht.

Damit ist nicht belegt, welche maximale Wirkung ein Angreifer in derselben Situation hätte erzielen können. Belegt ist aber, dass die Berechtigungskette bis zu einer realen Code-Aktion reichte.

Coding-Agenten werden Teil der Identity-Angriffsfläche

Bei klassischen Account-Takeovers ist die Frage meist, auf welche Anwendungen sich ein kompromittiertes Konto anmelden kann. Mit verbundenen Coding-Agenten kommt eine zweite Ebene hinzu.

Ein übernommenes Konto kann einen Agenten besitzen, der bereits Repository-Zugriff, Tool-Berechtigungen und gespeicherte Arbeitskontexte hat. Der Angreifer muss dann nicht jede nachgelagerte API selbst bedienen. Er kann die vorhandene Agenten-Identität als ausführenden Akteur verwenden.

Im Hacktron-Fall war genau diese Verbindung sichtbar: kompromittiertes Mitarbeiterkonto, verbundenes Codex, GitHub-Organisation, Pull Request.

Deshalb sollten Agenten-Credentials und menschliche SSO-Sessions nicht als dieselbe Vertrauensdomäne behandelt werden. Ein Coding-Agent braucht eine eigene Identität, einen begrenzten Repository-Scope und Berechtigungen, die nicht automatisch aus der vollen Session seines Besitzers entstehen.

Der Angriff war nicht autonom

Der Vorfall sollte nicht als autonomer Claude-Angriff beschrieben werden.

Hacktron führte die Untersuchung, wählte die Ziele und steuerte die Angriffskette. Claude half bei Analyse und Exploit-Entwicklung. Die Forscher entschieden, welche Ergebnisse weiterverfolgt wurden, und stoppten nach dem Proof of Concept.

Das unterscheidet den Fall deutlich von Cyber-Evals, in denen ein Agent über Stunden eigenständig Ziele auswählt und mehrere Schritte ohne fortlaufende menschliche Anleitung verkettet.

Trotzdem verschiebt sich die praktische Schwelle. Wenn ein kleines Team mit einem Frontier-Modell einen realen Memory-Corruption-Exploit schneller operationalisieren kann, wird Exploit-Engineering für mehr Akteure verfügbar. Dafür braucht es keine These über autonome Hacker-Agenten.

OpenAI schloss die gemeldete Lücke nach Hacktrons Zeitlinie noch am Tag der Meldung. Discourse veröffentlichte wenige Tage später eine Sicherheitskorrektur für die betroffene Komponente. Die Schwachstellen wurden also behoben.

Der interessantere Rest ist die Kette zwischen ihnen: ein öffentliches Forum, eine native Speicherlücke, eine Identity-Grenze und ein Coding-Agent mit Zugriff auf interne Entwicklungsinfrastruktur. Jede einzelne Ebene hatte ihre eigene Aufgabe. Zusammen reichten sie bis zu einer Code-Aktion im internen Repository.

Starten wir durch

Sollen wir uns das ansehen?

Erzählen Sie uns, was entstehen soll. Sie bekommen eine ehrliche Einschätzung zu Umfang, Zeitrahmen und Risiken — und eine klare Antwort, ob wir das richtige Team dafür sind.

Antwort in der Regel innerhalb von 24 Stunden