Hacktrons HEIF Heist: Eine ungepatchte Bildbibliothek öffnete die Tür zu OpenAIs Monorepo

Am 18. September 2026 veröffentlichte das Sicherheitsteam Hacktron AI eine mehrstufige Exploit-Kette, die mit einem gewöhnlichen Bild-Upload begann und in OpenAIs privatem Quellcode endete. Die technische Beschreibung mit dem Titel Hacking OpenAI schildert, wie drei Forscher in unter 72 Stunden das interne Monorepo des Unternehmens erreichten und wie ein Fix, der nie als Fix gekennzeichnet wurde, die Tür offen ließ.

Zum Weiterlesen: Eine Zero-Click-Lücke ließ bösartige Plugins Code in vier großen KI-Coding-Agenten ausführen · OpenAIs Agentenschwarm flutete RubyGems mit 2.000 schädlichen Gems, sagen Forscher.

Die Arbeit entstand am 25. Juli 2026 und wurde erst offengelegt, nachdem die betroffenen Projekte ihre Patches ausgeliefert hatten. Hacktron betont, dass der Weg nie ein falsch eingegebenes Passwort, eine Phishing-Mail oder einen kooperierenden Mitarbeiter erforderte. Er verband einen Speichersicherheitsfehler in einem Bild-Decoder mit einer Fehlkonfiguration der Identität und nutzte das eine, um das andere zu verstärken. Das Team aus Harsh Jaiswal, Mohan Pedhapati und Rahul Maini weitete die Decoder-Recherche später zu einer Kampagne aus, die es HEIF Heist nennt.

Wie die Kette funktionierte

Der dokumentierte Pfad hat vier Schritte, und jeder einzelne ist für sich genommen unspektakulär.

Schritt eins: Ein Bild erreicht eine C-Bibliothek. community.openai.com ist ein OpenAI-Forum, das auf Discourse läuft. Discourse prüft Uploads mit FastImage, das HEIC und HEIF nicht unterstützt, die Formate, die ein iPhone standardmäßig erzeugt. Dateien in diesen Formaten fallen an ImageMagicks magick-Befehl durch, der sie an libheif weitergibt, einen C/C++-Decoder. Im Bericht der Forscher genügte ein manipuliertes HEIC-Bild, um vom Angreifer kontrollierte Bytes direkt in einen nativen Parser zu schicken.

Schritt zwei: Der Parser bricht. libheif enthielt einen Heap-Pufferüberlauf, geführt als CVE-2026-32882 mit einem CVSS-Wert von 8,8. Wird er beim HEIC-Dekodieren ausgelöst, entstehen Auslese- und Schreibprimitive außerhalb der Grenzen, und das Team verwandelte sie in Remote-Code-Ausführung auf dem Forum-Container. Das entscheidende Detail liegt in der Geschichte dieses Codes: Upstream hatte ihn rund ein Jahr zuvor in einem routinemäßigen Aufräum-Commit geändert, der keinen Sicherheitshinweis und kein CVE trug. Debian portierte die Änderung deshalb nie zurück. Debian 12 und Debian 13 lieferten beide eine verwundbare libheif-Version aus, und das auf Debian 12 basierende Docker-Image von Discourse übernahm sie. Debian veröffentlichte DSA-6417-1 für Debian 13 am 8. August 2026.

Schritt drei: Das Forum öffnet den Zugang zu OpenAI-Konten. Mit administrativer Remote-Code-Ausführung auf dem Forum missbrauchte das Team eine Fehlkonfiguration in OpenAIs Single Sign-on unter auth.openai.com. Das Forum bot „Sign in with OpenAI" an, sodass eine Sitzung auf community.openai.com Gewicht über OpenAIs Verbraucherprodukte hinweg hatte. Hacktron konnte die ChatGPT- und Codex-Sitzungen angemeldeter OpenAI-Mitarbeiter ohne jede Handlung des Opfers übernehmen. Die Forscher betonen, dass dieser Schritt ein Identitätsproblem von OpenAI war und keine Discourse-Schwachstelle, und dass jeder Erst- oder Drittanbieterdienst mit demselben SSO dieselbe Tür geöffnet hätte.

Schritt vier: Nachweis statt Diebstahl. Über den Codex eines Mitarbeiters, der mit OpenAIs GitHub-Organisation verbunden war, wies das Team das System an, einen harmlosen Pull Request, PR #1186742, im internen Monorepo openai/openai zu öffnen, und stoppte danach. Hacktron erklärt, keinen internen Code gelesen oder exfiltriert zu haben. Ein Pull Request aus dem Inneren der Unternehmensgrenze ist ein saubererer Beleg für Schreibzugriff als ein Screenshot, und es ist die Art Nachweis, auf die ein Bounty-Programm reagieren kann.

Ein Forum ist ein Ziel von geringem Wert, bis es an das Identitätssystem angeschlossen wird, das alles andere schützt. Genau diese Verbindung ritt Hacktron in die OpenAI-Konten hinein.

Warum der unmarkierte Fix die eigentliche Geschichte ist

Die Schlagzeile lautet, dass Forscher den internen Code eines KI-Unternehmens erreichten. Die übertragbarere Lehre betrifft das, was passiert, wenn Sicherheitsarbeit ohne Sicherheitskennzeichnung ausgeliefert wird.

Schwachstellendatenbanken richten sich nach Identifikatoren. Distributionen entscheiden anhand von Hinweisen, CVEs und Versionshinweisen, was sie zurückportieren. Wenn ein Speichersicherheits-Fix als routinemäßige Wartung unter einem neutralen Titel erscheint, löst keines dieser Signale aus. Die libheif-Änderung galt als Aufräumarbeit, also hatte das Ökosystem keinen Grund hinzusehen, und die verwundbare Version behielt ihren Platz in Container-Images, lange nachdem der Code an der Quelle korrigiert worden war. Die State of AI beschreibt die Exposition ähnlich: Der Fehler war behoben, aber niemand wusste, dass man das sagen müsste.

Diese Lücke ist nicht selten, und sie wird folgenreicher, je tiefer die Software-Stapel werden. Dieser Fehler saß nicht in einem Forum, einem Framework oder einer Anwendung. Er lag mehrere Schichten tiefer, in einem Decoder, der über Wrapper wie ImageMagick, libvips und sharp sowie über vorgefertigte Basis-Images in die Produktion gelangt, die kaum ein Team von Hand aktualisiert. Ein Unternehmen kann seine direkten Abhängigkeiten sorgfältig verfolgen und trotzdem durch eine transitive Abhängigkeit exponiert sein, die es nie aufgelistet hat.

Auch Versionsnummern allein sind keine verlässliche Prüfung. Eine Distribution kann einen Fix zurückportieren, ohne die sichtbare Upstream-Version zu ändern, und ein Container kann ein altes Systempaket festhalten, selbst nachdem die Anwendung darüber neu gebaut wurde. Die lilting.ch-Analyse bringt den Punkt auf den Begriff: Entscheidend ist, welche Version tatsächlich ausgeführt wird, was bedeutet, den Sicherheitshinweis der Distribution zusammen mit dem Paket-Changelog zu lesen, statt einer Zeichenkette in einer Lockdatei zu vertrauen.

Discourse handelte schnell, sobald der Bericht vorlag. Es ergänzte eine Sandbox um ImageMagick, lieferte am Montag, dem 27. Juli, einen Fix und veröffentlichte am 28. Juli 2026 den Hinweis GHSA-vhm9-85gw-x335. Die Sandbox ist der Teil, der zum Nachahmen taugt. Speichersicherheitsfehler in Bildparsern werden weiter auftreten, deshalb ist die dauerhafte Verteidigung die Annahme, dass ein Decoder kompromittiert wird, und der Platz, an dem eine Kompromittierung nicht bis zum Host reicht, statt der Wette, dass der nächste Patch rechtzeitig kommt.

Die Identitätsschicht machte aus einem Forum-Fehler ein Unternehmensproblem

Ein Community-Forum ist in den meisten Bedrohungsmodellen ein Ziel von geringem Wert. Es enthält Diskussionen, keine Geheimnisse. Diese Annahme zerbricht in dem Moment, in dem das Forum den eigenen Identitätsanbieter des Unternehmens für die Anmeldung nutzt.

Weil community.openai.com „Sign in with OpenAI" erlaubte, wurde eine Server-Kompromittierung im Forum zu einem Standbein im Identitätsfluss. Hacktron konnte die ChatGPT- und Codex-Sitzungen von Mitarbeitern und anderen aktiven Forumnutzern übernehmen, ohne jemanden zu täuschen. Die mögliche Reichweite ging über ChatGPT hinaus: Konten sind oft mit anderen Diensten verbunden, und die Forscher nennen GitHub, Slack und E-Mail unter den Integrationen, die eine übernommene Sitzung berühren könnte.

Die Lehre reicht weit über OpenAI hinaus. Jede Organisation, die Drittanbieter- oder Community-Angebote über ihr Unternehmens-Identitätssystem authentifizieren lässt, hat einen Pfad vom am wenigsten vertrauenswürdigen Dienst zu den vertrauenswürdigsten Konten geschaffen. Der Zuschnitt der Berechtigungen zählt hier ebenso wie das Patchen. Ein Anmeldetoken, das für ein Diskussionsforum ausgestellt wurde, sollte nicht die Autorität eines API-Zugangs für die Flaggschiffprodukte des Unternehmens tragen, und der Fix, den OpenAI einsetzte, betraf genau diese Identitätskonfiguration, nicht Discourse.

Der Cyber-Kendra-Bericht über die Offenlegung rahmt dieselbe Trennung: Das Forum war der Einstiegspunkt, aber die Eskalation, auf die es ankam, war das Vertrauen, das einer Sitzung gewährt wurde. Zu prüfen, welche Anwendungen für welche Zielgruppen Token ausstellen können, und die Lebensdauer dieser Token zu verkürzen, hilft gegen diese Angriffsklasse mehr als jeder einzelne Server-Patch.

KI-geschriebene Exploits veränderten das Tempo

Die Exploit-Entwicklung war einst ein Engpass, der Verteidiger begünstigte. Ein Auslese- oder Schreibprimitiv außerhalb der Grenzen in eine zuverlässige Nutzlast zu verwandeln bedeutet, die Adressraum-Randomisierung zu überwinden und den Allokator des Ziels zu treffen, Arbeit, die einen Spezialisten Tage oder Wochen kostete.

Hacktrons Bericht zeigt, wie dieser Engpass dünner wird. Das Team erklärt, Claude Opus 4.8 habe das Discourse-Image analysiert und festgestellt, dass Sicherheitsfixes nicht in dessen libheif-Paket zurückportiert worden waren, aber über mehrere Sitzungen keinen funktionierenden Exploit mit aktiviertem ASLR erzeugt. Stunden, nachdem Anthropic Claude Opus 5 ausgeliefert hatte, lieferte dieselbe Aufgabe in etwa drei Stunden einen funktionierenden ARM64-Exploit. Das Team ließ das Modell ihn dann auf die x86-64- und jemalloc-Konfiguration portieren, die Discourse nutzt, und am frühen Morgen des 25. Juli war Code-Ausführung über einen Bild-Upload bestätigt.

Die Forscher betrieben das Modell in einer autonomen Schleife gegen eine Instanz, die sie kontrollierten und die wie ein Capture-the-Flag-Ziel aussah, weil das Modell sich geweigert hatte, einen Exploit für ein Live-System zu schreiben. Dasselbe generierte Skript funktionierte dann gegen OpenAIs Forum. Mitnehmen sollte man nicht, welches Modell gewann, sondern dass sich die Grenze innerhalb eines einzigen Release-Zyklus von „kein funktionierender Exploit" zu „funktionierender Exploit in drei Stunden" verschob und dass die schwierigen, repetitiven Teile der Ausnutzung genau die sind, an denen ein Agent arbeiten kann.

Worauf zu achten ist

Drei Dinge entscheiden, wie wichtig diese Geschichte bleibt. Das erste ist, ob die übrigen HEIF-Heist-Ergebnisse zu Sicherheitshinweisen werden. Hacktron erklärt, dieselbe Decoder-Klasse habe Slack, Metas Kernprodukte, Next.js und GitHub Enterprise Server erreicht, wo ein verwandter Fehler als CVE-2026-19118 geführt und am 1. September 2026 in Version 3.21.5 behoben wurde. Vercel deaktivierte die AVIF-Optimierung in seinem Managed Service, solange der Upstream-Fix sich verbreitete. Bestätigen weitere Anbieter ähnliche Pfade, verschiebt sich die Lehre von einem Forum auf die gesamte Bildverarbeitungs-Lieferkette.

Das zweite ist, wie schnell nachgelagerte Nutzer tatsächlich reagieren. Nutzer von Upstream-libheif sollten 1.23.2 oder neuer erreichen, und Mitte September 2026 war 1.23.4 die jüngste Sicherheitsversion. Wo HEIF- oder AVIF-Dekodierung nicht gebraucht wird, sollte sie auf Anwendungsebene abgeschaltet werden. Wo sie gebraucht wird, gehört die Bildverarbeitung in eine gehärtete, flüchtige Sandbox, wie Discourse sie nun nutzt.

Das dritte ist der Zuschnitt der Identität. Der OpenAI-Befund wurde etwa 14 Stunden nach dem Bericht gepatcht, und das Unternehmen zahlte ein Bounty von 6.500 Dollar, während es feststellte, dass die Tests gegen das Forum selbst außerhalb seines Bug-Bounty-Rahmens lagen. Diese Aufteilung beschreibt fair, wo der Fehler lag, bedeutet aber auch, dass die am besten wiederverwendbare Lehre, dass ein Community-Forum kein Generalschlüssel sein sollte, in der Branche noch verarbeitet wird.

Titelbild: Wikimedia Commons „Person holding the OpenAI icon.jpg" von FoxTPNL, CC BY 4.0 (auf 16:9 zugeschnitten).