Von der Backport-Lücke zum OpenAI-Konto

Ein Docker-Image mit unbackportierter libheif-Lücke plus eine SSO-Schwäche öffneten OpenAI-Konten. Claude Opus 5 baute den Exploit in Stunden statt Tagen.

7 Min. Lesezeit

Das Sicherheitsteam Hacktron hat im Juli über einen Bild-Upload im OpenAI-Hilfeforum Zugriff auf ChatGPT- und Codex-Konten von OpenAI-Mitarbeitenden bekommen, und von dort aus auf interne GitHub-Repositories. Der Bericht dazu ist am 18.09.2026 erschienen. Wir haben ihn gegen die zugehörigen Advisories geprüft.

Die Kette

OpenAI betreibt sein Forum community.openai.com mit Discourse und lässt Login per "Sign in with OpenAI" zu. Hacktron vermutete, dass ein Einbruch ins Forum über diesen Identitätsweg auch Zugriff auf andere OpenAI-Dienste öffnen könnte, und suchte nach einem Weg ins Forum hinein.

Discourse prüft Bilder normalerweise mit FastImage, das aber kein HEIC beherrscht. Für HEIC- und HEIF-Dateien reicht Discourse deshalb an ImageMagick weiter, und ImageMagick ruft dafür die Bibliothek libheif auf. Genau dort setzte der Angriff an: Ein hochgeladenes Bild landete direkt im libheif-Parser.

Die Lücke selbst ist keine Neuentdeckung. Sie steckt in der Überlagerungsberechnung von libheif und trägt die Kennung CVE-2026-32882, veröffentlicht am 19.05.2026 mit einem CVSS-Wert von 7,1, behoben mit Version 1.22.0. Discourses Docker-Image basierte aber auf Debian, und Debian 12 wie Debian 13 lieferten zum Zeitpunkt des Angriffs noch die verwundbaren Versionen 1.19.7 beziehungsweise 1.19.8 aus. Der Fix war seit Mai öffentlich, nur eben noch nicht bis zum Betriebssystem-Paket durchgereicht. Debian hat das Paket erst am 08.08.2026 mit DSA-6417-1 gepatcht, gebündelt mit elf weiteren libheif-CVEs.

Zwei Modelle, ein Sprung dazwischen

Am 23.07.2026 ließ Hacktron einen Agenten mit Claude Opus 4.8 das installierte libheif-Paket im Discourse-Docker-Image durchsehen. Der Agent fand die fehlende Rückportierung. Am 24.07.2026 baute Opus 4.8 daraus einen Exploit, der allerdings nur ohne ASLR funktionierte. Mehrere weitere Sitzungen scheiterten daran, ihn gegen Discourses Standardkonfiguration mit aktiviertem ASLR zuverlässig zu machen.

Am selben Abend veröffentlichte Anthropic Claude Opus 5. Hacktron gab dem neuen Modell dieselbe Aufgabe, und es lieferte innerhalb von drei Stunden einen funktionierenden Exploit für einen lokalen Mac mit ARM64. Anschließend portierte es ihn auf die x86-64-Umgebung mit jemalloc, wie sie bei Discourse läuft. Am Morgen des 25.07.2026 stand ein bestätigtes lokales RCE über einen Bild-Upload.

Danach ließ Hacktron das Modell autonom gegen die eigene Discourse-Cloud-Instanz laufen, über einen Proxy als CTF-Ziel getarnt, weil Opus einen Exploit gegen eine echte Fremdinstanz zunächst verweigerte. Am selben Vormittag stand auch dort ein RCE, belegt über einen Lesezugriff auf /etc/hosts.

Datum (UTC)Ereignis
23.07.2026Opus 4.8 findet die fehlende Rückportierung im Docker-Image
24.07.2026Opus 4.8 baut Exploit ohne ASLR, scheitert mit ASLR
24.07.2026, abendsOpus 5 erscheint, liefert in 3 Stunden lokalen ARM64-Exploit
25.07., 05:00-06:00Bestätigtes RCE via Bild-Upload
25.07., 08:00-10:00Meldung an OpenAI über Bugcrowd
25.07., 13:30-15:30Zugriff auf Mitarbeiterkonto, PoC-Pull-Request, Tests gestoppt
25.07., 22:49OpenAI bestätigt den Fix
28.07.2026Discourse-Advisory GHSA-vhm9-85gw-x335 veröffentlicht
01.09.2026OpenAI zahlt 6.500 US-Dollar Bounty

Den letzten Schritt, vom Forum-RCE zur Kontoübernahme, lieferte erst eine zweite, separate Schwachstelle im OpenAI-SSO. Hacktron betont, dass die Eskalation nicht an Discourse hängt. Jeder Dienst mit OpenAI-Anmeldung hätte als Einstieg denselben Zugriff geöffnet. Die Bounty von 6.500 Dollar deckt laut OpenAI-Kommentar im Bericht nur den SSO-Fund ab, Tests gegen die von Discourse gehostete Instanz waren vom Bug-Bounty-Programm ausdrücklich ausgeschlossen.

Hacktron selbst ordnet die Rolle der Modelle nüchtern ein: "This was not completly autonomous hacking, and skilled human guidance remained important." Die Strategie, welches Ziel überhaupt verfolgt wird, kam vom Team. Was sich beschleunigt hat, ist die Zeit zwischen Idee und funktionierendem Exploit-Code.

Nicht nur Discourse

Hacktron hat aus dem Fund eine Kampagne gemacht und nennt sie "HEIF Heist". Laut Übersichtsseite betrifft sie jeden Dienst, der Bilder in HEIF, HEIC oder AVIF von außen annimmt und mit libheif oder libde265 dekodiert. Genannt werden unter anderem Slack, Meta, GitHub Enterprise und mehrere Web-Frameworks.

Für viele von euch am wichtigsten ist Next.js. Vercel hat am 25.08.2026 eine Lücke veröffentlicht, die aus libheif stammt und über die Image Optimization mit einer präparierten AVIF-Datei zu Remote Code Execution ohne Anmeldung führen kann. Auf Vercel gehostete Anwendungen sind geschützt, dort wurde die AVIF-Optimierung abgeschaltet. Wer Next.js selbst betreibt, muss auf 15.5.24 oder 16.3.3 aktualisieren. In diesen Versionen werden AVIF-Bilder bis auf Weiteres unverändert ausgeliefert statt verarbeitet.

Zwei Beobachtungen aus dem Hacktron-Bericht sind unbequem. Die Modelle passten den Exploit meist in ein bis zwei Tagen an ein neues Ziel an, ohne die genaue libheif-Version oder die Umgebung zu kennen. Und bemerkt hat das nach Hacktrons Kenntnis nur Shopify, obwohl tausende Bilder hochgeladen wurden und die Bildverarbeitung wiederholt abstürzte.

Was das für euch heißt

Der Hebel war eine seit Monaten bekannte Lücke, die außerhalb der eigenen Abhängigkeitsliste lag. Discourse bindet libheif nicht direkt ein, die Bibliothek kam über ImageMagick und das Debian-Basis-Image mit. In keinem Lockfile von Discourse taucht sie auf, ein Scan dort findet sie also nicht.

Wer Bilder von Nutzern annimmt und dafür Formate wie HEIC, HEIF oder AVIF unterstützt, sollte die Bildverarbeitung als eigene Angriffsfläche behandeln, nicht als Nebensache der Upload-Funktion. Praktisch heißt das: Bildverarbeitung in einem eigenen, möglichst rechtearmen und kurzlebigen Prozess laufen lassen, statt im selben Kontext wie der Rest der Anwendung. ImageMagicks eigene Sicherheitsrichtlinie erlaubt es außerdem, akzeptierte Formate und Ressourcenverbrauch einzuschränken, das lohnt einen Blick, wenn HEIC-Support nicht zwingend gebraucht wird.

Behaltet außerdem im Blick, wie oft eure Bild-Worker abstürzen. Gehäufte Crashes in der Bildverarbeitung sind genau das Muster, das bei den meisten Zielen der Kampagne niemandem aufgefallen ist.

Und der Patch-Status von Container-Basis-Images gehört in denselben Blick wie der eigene Lockfile. Ein CVE kann seit Monaten öffentlich und behoben sein und trotzdem produktiv laufen, einfach weil die Distribution den Fix noch nicht zurückportiert hat. Wer Base-Images baut oder zieht, sollte regelmäßig neu bauen, nicht nur beim eigenen Code-Release.

Das ist dieselbe Linie wie in Zehn Minuten vom Patch zum Angriff und Zehn Stunden, fünf Agenten, kein Zero-Day. Neu ist, wie wenig Zeit und wie wenig Wissen über das Zielsystem inzwischen zwischen einer bekannten Schwäche und einem funktionierenden Angriff liegen.

Quellen6