Ein autonomer KI-Agent arbeitete sich in unter 72 Stunden von einem hochgeladenen Foto bis in das interne Code-Repository von OpenAI vor. Die Sicherheitsfirma Hacktron nutzte dafür eine Speicherlücke in der Bildbibliothek libheif, nicht eine Schwäche im KI-Modell selbst. Der Fall zeigt, wie günstig maschinell entwickelte Angriffe geworden sind und warum jede Foto-Upload-Funktion zur Angriffsfläche wird.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Ein einziges HEIC-Bild und ein KI-Agent reichten als Türöffner zu OpenAI. Am 25. Juli 2026 lud das Team von Hacktron ein präpariertes Foto in das Community-Forum, übernahm den Server und erreichte darüber die ChatGPT- und Codex-Konten der Mitarbeiter. Zum Beleg legte es einen harmlosen Eintrag im internen Code-Repository an und stoppte.
Das Wichtigste in Kürze
- Zwei verkettete Lücken führten in unter 72 Stunden vom Bild-Upload bis in OpenAIs internes Repository.
- Die eigentliche Schwachstelle steckt in der quelloffenen Bildbibliothek libheif, nicht im KI-Modell.
- Einen funktionierenden Exploit schrieb ein KI-Agent binnen Stunden, die Kampagne kostete unter 2.600 Euro.
- Betroffen ist jeder Dienst, der hochgeladene HEIF- oder AVIF-Bilder serverseitig verarbeitet.
Wie kam ein KI-Agent an OpenAIs internen Code?
Zwei verkettete Lücken ebneten den Weg. Das OpenAI-Forum läuft auf der Software Discourse, die hochgeladene HEIC-Bilder zur Umwandlung an ImageMagick und weiter an libheif reicht. Dort löste ein präpariertes Foto einen Heap-Überlauf aus und erlaubte fremden Code auf dem Server. Ein zweiter Fehler im Single Sign-on von OpenAI machte aus dieser Server-Kontrolle den Zugriff auf die Konten angemeldeter Mitarbeiter.[1]
Den Exploit schrieb kein Mensch von Hand. Hacktron setzte einen KI-Agenten auf Basis von Anthropics Claude in eine autonome Schleife, der trotz aktiver Speicherverwürfelung binnen Stunden einen funktionierenden Angriffscode lieferte. Dieselbe Technik, die inzwischen Sicherheitslücken im Code aufspürt, schreibt jetzt die Angriffe. OpenAI schloss die eigene Lücke noch am selben Tag über sein Bugcrowd-Programm und zahlte später gut 5.600 Euro; die Tests gegen das Discourse-Forum lagen laut OpenAI aber außerhalb des Programms.
Warum liegt die Lücke gar nicht bei OpenAI?
Der Speicherfehler sitzt in libheif, einem in C und C++ geschriebenen Decoder für HEIF- und AVIF-Bilder. Ein Heap-Überlauf erlaubt dort Lese- und Schreibzugriffe außerhalb der Grenzen, der klassische Fehler unsicherer Speichersprachen. Die Bibliothek liegt tief in der Lieferkette, die kaum ein Team ganz kennt. Discourse zog die verwundbare Version direkt aus Debian 12.
Ein Wartungsteam von einer Person trägt diese Last. Die Recherche HEIF Heist fand dieselbe Bibliothek in Slack, Meta, GitHub Enterprise und in den Bild-Pipelines von Next.js, Astro und Gatsby.[2] libheif und der Zulieferer libde265 werden von einem einzigen Entwickler fast ohne Förderung gepflegt, allein 2026 fielen 37 Sicherheitshinweise an. Schon 2023 traf die Bildbibliothek libwebp mit der Lücke CVE-2023-4863 nahezu alle großen Browser. Ein Umstieg auf speichersichere Sprachen braucht Jahre, bis er solche Altbibliotheken erreicht.
Nicht das Sprachmodell von OpenAI ist gefallen, sondern eine Bildbibliothek, die kein Einkauf je bestellt hat. Jeder Betrieb, der Bilder von Nutzern annimmt, betreibt fremden C-Code im eigenen Rechenzentrum und haftet dafür.
— Michael Dobler, Herausgeber Dr. Web
Was bedeutet das für Unternehmen im DACH-Raum?
Regulatorischer Druck verschärft die Lage. Unter dem NIS2-Umsetzungsgesetz und dem EU Cyber Resilience Act liegt die Verantwortung für eine verwundbare Komponente beim Betreiber, nicht beim ehrenamtlichen Ursprungsprojekt. Eine Software-Stückliste wird zur Pflicht, damit ein Betrieb seine nativen Bibliotheken überhaupt kennt. Die Werkzeuge der Künstlichen Intelligenz senken derweil die Kosten für Angriff wie Verteidigung.
Konkrete Schritte folgen daraus. Ratsam sind eine Inventur der eigenen Bildverarbeitung, das Abschalten nicht benötigter HEIF- und AVIF-Delegates in ImageMagick, aktuelle Versionen von libheif und libde265 sowie eine abgeschottete Bildkonvertierung. Ebenso gehören Verbindungen zwischen Diensten aufs Nötigste beschränkt, denn ein einzelnes Forum-Konto reichte bis zum internen Code. Schon ein KI-Sicherheitstest bei Meta zeigte, wie ein Modell im offenen Internet ein fremdes Unternehmen erreichte. Betriebe mit Foto-Uploads prüfen diese Kette jetzt, bevor es ein Angreifer tut.
Was ist die libheif-Sicherheitslücke?
libheif ist eine quelloffene Bibliothek zum Decodieren von HEIF- und AVIF-Bildern. In der betroffenen Version erlaubt ein Heap-Überlauf beim Verarbeiten eines präparierten Bildes das Lesen und Schreiben außerhalb der Speichergrenzen, woraus sich die Ausführung fremden Codes entwickeln lässt.
Wurde OpenAI selbst gehackt?
Sicherheitsforscher von Hacktron erreichten über das OpenAI-Community-Forum kurzzeitig Konten von Mitarbeitern und legten einen harmlosen Eintrag im internen Repository an. OpenAI schloss die eigene Lücke am selben Tag und zahlte eine Prämie. Der Kern der Lücke lag in einer Bildbibliothek, nicht im KI-Modell.
Welche Systeme sind von der HEIF-Lücke betroffen?
Betroffen ist grundsätzlich jeder Dienst, der hochgeladene HEIF- oder AVIF-Bilder serverseitig über libheif verarbeitet. Die Recherche HEIF Heist wies die Bibliothek unter anderem in Slack, GitHub Enterprise und in den Bild-Pipelines von Next.js, Astro und Gatsby nach.
Wie schützen Unternehmen ihre Bild-Uploads?
Wichtig sind vier Schritte: die eigene Bildverarbeitung inventarisieren, nicht benötigte HEIF- und AVIF-Delegates in ImageMagick abschalten, libheif und libde265 aktuell halten und jede Bildkonvertierung in einem abgeschotteten Prozess laufen lassen. Ergänzend sollten Dienst-Verbindungen streng begrenzt werden.
Quellen
[1] Hacktron: „Hacking OpenAI“
[2] HEIF Heist: Untersuchung zur Verbreitung der libheif-Lücke
Mehr Newshunger?
- MAI-Cyber-1-Flash: Microsofts KI-Modell findet Sicherheitslücken und schreibt den Patch
- Gemini 3.6 Flash und 3.5 Flash Cyber: Google verbilligt die KI und jagt Sicherheitslücken
- GitLab-Lücke CVE-2026-19478: Der Patch lieferte die Bauanleitung
- Metabase-Sicherheitslücke: Angreifer stehlen Kundendaten über die Analyse-Plattform
- Dependabot wartet jetzt drei Tage: GitHubs neue Standard-Wartezeit gegen Lieferketten-Angriffe
- Wie WordPress 7.0.4 eine Sicherheitslücke beim Datei-Upload behebt
