Skip to content
enterprise

Wie ein Foto das Königreich von OpenAI hackte

Eine einzige Bilddatei umging die Sicherheitsvorkehrungen von OpenAI und führte zu einer Kompromittierung von GitHub. Dieser Angriff offenbart eine stille Schwachstelle, die in Millionen von Anwendungen lauert, und Ihr Stack ist wahrscheinlich als Nächstes dran.

Eleanor Shaw
Wie ein Foto das Königreich von OpenAI hackte

Das Trojanische Pferd in Ihrer Kamerarolle

Eine bösartige Bilddatei, speziell ein HEIC-Foto – das Standardformat für iPhones –, wurde zum unerwarteten Einfallstor in die Systeme von OpenAI. Angreifer luden diese scheinbar harmlose Datei in das Community-Forum von OpenAI hoch, das auf der Discourse-Plattform betrieben wird. Diese scheinbar geringfügige Aktion löste eine kritische Schwachstellenkette aus und verwandelte ein gewöhnliches Bild in ein digitales Trojanisches Pferd.

Das primäre Bildverarbeitungstool von Discourse, FastImage, unterstützte HEIF-Dateien nicht. Als FastImage auf den nicht unterstützten HEIC-Upload stieß, umging es daher seine üblichen Prüfungen und leitete die Datei an ImageMagick weiter. ImageMagick übergab diese ungeprüfte Eingabe dann direkt an die zugrunde liegende libheif-Bibliothek, die für die Dekodierung von HEIC-Dateien entwickelt wurde.

Diese direkte Pipeline war äußerst gefährlich. Sie ermöglichte es einer vom Angreifer kontrollierten Datei, direkt mit einem Low-Level-Parser, libheif, zu interagieren, der eine ungepatchte Schwachstelle enthielt. Der Exploit war möglich, weil ein kritischer Fix für libheif nicht als Sicherheits-Patch gekennzeichnet worden war, was verhinderte, dass Debian ihn zurückportierte. Daher lieferte das Docker-Image von Discourse, das auf Debian 12 basiert, weiterhin die anfällige Version aus und schuf ein perfektes Zeitfenster für die Remote-Code-Ausführung.

Ein Geister-Patch in der Lieferkette

Eine kritische Schwachstelle war nichts Neues; die Entwickler von libheif hatten den Fehler tatsächlich ein ganzes Jahr vor dem OpenAI-Hack behoben. Dieser Upstream-Fix trug jedoch keine Sicherheitskennzeichnung, ein Versäumnis, das sich als äußerst kostspielig erweisen sollte.

Entscheidend ist, dass die Entwickler den Patch nie als Sicherheits-Fix markierten und er auch keine CVE-ID (Common Vulnerabilities and Exposures) erhielt. Dieses Kommunikationsversagen schuf einen kritischen blinden Fleck, der verhinderte, dass nachgelagerte Systeme die Notwendigkeit des Updates erkannten. Ohne diese Standardkennung blieb der Fix für automatisierte Sicherheitsprozesse und Schwachstellenscanner unsichtbar.

Dieses Versäumnis führte zu einem kaskadierenden Ausfall der Lieferkette. Debian – eine grundlegende Linux-Distribution, die unzählige Server antreibt – hat den wesentlichen Patch nie in seine stabile Version zurückportiert. Jedes System, das sich auf den stabilen Zweig von Debian verlässt und gründlich geprüften Code erwartet, hat unwissentlich die ungeprüfte Schwachstelle übernommen.

Das auf Discourse basierende Community-Forum von OpenAI, das auf einem auf Debian 12 basierenden Docker-Image betrieben wurde, lieferte folglich den veralteten, anfälligen Code aus. Dieses Fehlen eines Sicherheits-Flags bedeutete, dass das Forum mit einer bekannten, ausnutzbaren Schwachstelle lief, ohne dass die Betreiber davon wussten. Der Geister-Patch ließ das digitale Königreich unwissentlich ungeschützt.

Vom Forum-Administrator zum GitHub-Committer

Die Kompromittierung des auf Discourse basierenden Community-Forums war nur der erste Schritt. Angreifer nutzten eine kritische Fehlkonfiguration innerhalb des eigenen Single Sign-On (SSO)-Systems von OpenAI aus. Dieser architektonische Fehler bedeutete, dass die Erlangung der administrativen Kontrolle über das öffentliche Forum die Tür zu einem weitaus sensibleren Bereich öffnete: interne Mitarbeiterkonten.

Forscher nutzten diese SSO-Schwachstelle aus, um Mitarbeiterkonten sowohl für ChatGPT als auch für Codex zu kompromittieren. Diese direkte Verbindung zwischen einem öffentlich zugänglichen Forum und zentralen internen Entwicklungstools zeigt einen schwerwiegenden Zusammenbruch der Zugriffskontrolle. Ein scheinbar isolierter Foren-Hack verwandelte sich in eine direkte Bedrohung für geistiges Eigentum und betriebliche Integrität.

Als definitiven Beweis für ihren tiefen Zugriff war eines der kompromittierten Mitarbeiterkonten direkt mit der internen GitHub-Organisation von OpenAI verbunden. Die Forscher öffneten erfolgreich einen pull request von diesem Konto, was ihre unbefugte Präsenz eindeutig demonstrierte, bevor sie die Sicherheitslücke verantwortungsbewusst meldeten. OpenAI zahlte später ein Kopfgeld von 6.500 $ für diese kritische Entdeckung. Für einen tieferen Einblick in die Methodik, erkunden Sie Hacking OpenAI | Hacktron AI.

Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.

eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte

Der Bug, der Big Tech verfolgt

Die libheif-Schwachstelle reicht weit über die spezifische Infrastruktur von OpenAI hinaus und offenbart ein systemisches Risiko, das tief in der digitalen Lieferkette verwurzelt ist. Dies ist keine obskure Bibliothek; sie dient als kritische Abhängigkeit in riesigen Technologie-Ökosystemen und treibt stillschweigend die Bildverarbeitung für Branchenriesen an. Ihre Reichweite umfasst:

  • Slack
  • Meta
  • GitHub Enterprise
  • Weit verbreitete Web-Frameworks wie Rails und Next.js

Forscher demonstrierten schnell die weit verbreitete Replizierbarkeit dieses Exploits. Die Anpassung des Angriffsvektors für diese anderen großen Unternehmen erforderte nur ein oder zwei Tage, was ein allgegenwärtiges, ungelöstes Risiko in der Technologielandschaft unterstreicht. Ein einziges, bösartig erstelltes HEIC- oder AVIF-Bild könnte kritische Türen öffnen und herkömmliche Sicherheitsüberprüfungen umgehen.

Diese weit verbreitete Gefährdung erfordert sofortiges, entschlossenes Handeln. Sicherheitsteams und Entwickler müssen ihre gesamte Abhängigkeitskette unverzüglich prüfen, wobei der Schwerpunkt auf Bildverarbeitungsbibliotheken liegen sollte. Überprüfen Sie, welche Version von libheif aktiv in jeder Anwendung läuft, die HEIC- oder AVIF-Bild-Uploads verarbeitet. Denken Sie daran, dass der ausgenutzte Bug ein Jahr zuvor upstream gepatcht wurde, aber aufgrund des Fehlens einer CVE oft nicht angewendet wurde.

Proaktives Patchen ist nicht nur eine bewährte Methode, sondern ein Gebot. Die Kosten des Nichtstuns – potenzielle Datenschutzverletzungen, Reputationsschäden und betriebliche Unterbrechungen – überwiegen bei weitem die Investition in ein wachsames Abhängigkeitsmanagement. Sichern Sie Ihren Perimeter, indem Sie Ihre zugrunde liegenden Komponenten sichern.

Häufig gestellte Fragen

Was war die Kernschwachstelle, die den OpenAI-Hack ermöglichte?

Der Hack nutzte eine Schwachstelle in libheif aus, einer Open-Source-Bibliothek, die zur Verarbeitung von HEIC-Bilddateien verwendet wird. Da die Bibliothek tief im Anwendungs-Stack verschachtelt war, konnte ein speziell präpariertes Bild bösartigen Code ausführen.

Wie eskalierten die Angreifer von einem Forum zu OpenAI's GitHub?

Ein falsch konfiguriertes Single-Sign-On-System (SSO) verband das OpenAI-Community-Forum mit internen Mitarbeiterkonten. Durch die Kompromittierung des Forums konnten Angreifer dazu übergehen, ChatGPT- und Codex-Konten zu übernehmen, von denen eines Zugriff auf OpenAI's GitHub hatte.

Warum wurde diese bekannte Schwachstelle nicht gepatcht?

Obwohl der Bug ein Jahr zuvor im Hauptcode von libheif behoben worden war, wurde der Fix nie als Sicherheitsproblem gekennzeichnet und erhielt keine CVE. Infolgedessen haben Distributionen wie Debian den Patch nicht zurückportiert, wodurch abhängige Software wie das Docker-Image von Discourse anfällig blieb.

Ist diese Schwachstelle auf OpenAI beschränkt?

Nein. Dieselbe libheif-Bibliothek wird von großen Plattformen und Frameworks verwendet, darunter Slack, Meta, GitHub Enterprise, Ruby on Rails und Next.js. Jede Anwendung, die HEIC- oder AVIF-Datei-Uploads akzeptiert, könnte gefährdet sein, wenn sie eine anfällige Version ausführt.

Found this useful? Share it.

For builders

Want Stork to write one of these about your product?

Send us a URL. We use the product, form a view, and publish what we actually think — in 8 languages, labeled Sponsored, with no copy approval on your side. That last part is what makes it worth quoting.

See how it works$500 · AI tools & software only

Für Builder

Diese Seite arbeitet gerade für das Tool von jemand anderem.

KI-Agenten lesen sie. Käufer landen darauf. Sie antwortet in acht Sprachen und über MCP. Dein Tool kann so eine haben — in 24 Stunden live.