OpenAI-Konto-Übernahme: Forscher kombinieren libheif-Heap-Overflow und SSO-Schwäche zur vollständigen Übernahme
Dem Hacktron-Team gelang der Einstieg über eine einzige hochgeladene Bilddatei. Ein Heap-Overflow in libheif wurde mit einer Schwachstelle im SSO-Flow verkettet und führte bis zum Zugriff auf interne Repositories.
Veröffentlicht am 16. Oktober • Zuerst veröffentlicht auf faizanakhtarcyber.blogspot.com
Originalrecherche des Hacktron-AI-Teams (Harsh Jaiswal, Mohan Pedhapati, Rahul Maini) – den vollständigen Bericht finden Sie hier: https://www.hacktron.ai/blog/hacking-openai · Profil des Forschers: https://www.hacktron.ai
Ein einziger Foto-Upload war der gesamte Einstiegspunkt in eines der meistbeobachteten Unternehmen des Planeten. Im Juli 2026 verwandelten drei Forscher von Hacktron AI ein präpariertes HEIF-Bild in Remote Code Execution auf dem Community-Forum von OpenAI und überschritten dann eine weitreichendere Grenze: Ein Identitätsfehler im Single Sign-On von OpenAI ermöglichte es ihnen, die ChatGPT- und Codex-Konten aller Personen zu übernehmen, die sich lediglich in dieses Forum eingeloggt hatten, einschließlich Mitarbeitern. Der mit GitHub verbundene Codex eines Mitarbeiters öffnete daraufhin einen Pull Request im privaten internen Monorepo von OpenAI – der Zugriffsnachweis war erbracht, kein Code gelesen, die Tests beendet.
Dies ist meine eigene Analyse ihrer öffentlich offengelegten Forschung: wie die beiden Schwachstellen gefunden wurden, warum die Angriffskette funktionierte und was Hunter und Verteidiger daraus mitnehmen sollten.
Harsh Jaiswal, Mohan Pedhapati und Rahul Maini, die als Hacktron AI arbeiten, wollten die Sicherheitslage von KI-Frontier-Unternehmen untersuchen und wählten das Community-Forum von OpenAI unter community.openai.com, das auf Discourse basiert und „Sign in with OpenAI“ anbietet. Was sie fanden, war nicht eine Schwachstelle, sondern zwei Defekte mit einer Brücke dazwischen: ein Memory-Corruption-Problem in der Bildpipeline des Forums und eine SSO-Schwäche, die den Vordereingang des Forums als Durchgang zu den Konten der Mitarbeiter behandelte.
Die Zeitleiste liest sich wie ein Sprint. Am 23. Juli verfolgten sie den HEIF-Upload-Pfad des Forums bis zum verwundbaren Decoder; am 24. Juli hatten sie einen funktionierenden Exploit mit deaktiviertem ASLR; am Morgen des 25. Juli erreichten sie zuverlässige Codeausführung gegen das Live-Forum, und am Nachmittag desselben Tages öffneten sie den Zugriffs-Nachweis als Pull Request und beendeten die Tests – von der Entdeckung bis zum Zugriff auf das interne Repository in weniger als 72 Stunden. Den SSO-Befund meldeten sie über das Bugcrowd-Programm von OpenAI; OpenAI behob die Schwachstelle rund 14 Stunden nach der Meldung und zahlte 6.500 US-Dollar nur für den OpenAI-seitigen Fund (das Forum selbst lag außerhalb des Scope des Bug-Bounty-Programms).
Das Problem auf Forumsseite ging an das HackerOne-Programm von Discourse: an einem Samstag erhalten, an einem Sonntag beantwortet, am Montag behoben. Der Bericht wurde Mitte September 2026 veröffentlicht, zusammen mit einer breiter angelegten Kampagne, die dieselbe Decoder-Schwäche auf anderen Plattformen nachverfolgte.
Ein Heap Buffer Overflow in libheif, erreichbar über die Bildpipeline des Forums. Discourse prüft Uploads mit FastImage, aber FastImage konnte HEIF-Dateien nicht parsen, weshalb diese Uploads an den Befehl magick von ImageMagick weitergeleitet wurden, der das HEIF-Decoding an die Bibliothek libheif delegiert. Diese Delegierung legte den rohen libheif-Parser angreiferkontrollierten Dateien offen, und der Decoder enthielt einen Heap Buffer Overflow, der Out-of-Bounds-Read- und Write-Primitives ermöglichte.
Das Supply-Chain-Detail macht diesen Fall zu Lehrbuchmaterial: Der fehlerhafte Code war upstream bereits korrigiert worden, aber der Commit wurde nie als Sicherheitsfix gekennzeichnet und erhielt kein CVE. Als gewöhnliche Wartung behandelt, wurde er nie zurückportiert – das Docker-Image von Discourse (Debian 12) lieferte weiterhin das verwundbare libheif 1.19.7 aus, und Debian 13 lieferte ebenfalls das verwundbare 1.19.8. Ein Fix, der für diejenigen unsichtbar ist, die über Backports entscheiden, ist aus Sicht des Angreifers kein Fix.
Ein OpenAI-SSO-Identitätsfehler, der die Vertrauensgrenze überschritt. Das Forum nutzte „Sign in with OpenAI“ über auth.openai.com. Der zweite Fehler steckte darin, wie die Identitätsschicht von OpenAI diese Anmeldung eingrenzte: Mit Codeausführung auf dem Forum konnten die Forscher die ChatGPT- und Codex-Konten aller Personen übernehmen, die sich über diesen SSO-Flow angemeldet hatten – Mitarbeiter eingeschlossen –, ohne jegliche Interaktion der Opfer. Da ChatGPT und Codex mit Diensten wie GitHub, Slack und E-Mail verbunden sind, weitete sich die Reichweite auf alles aus, was diese Verbindungen berühren konnten. Die Eskalation ist nicht Discourse-spezifisch: Jeder kompromittierte Dienst mit derselben SSO-Vereinbarung hätte denselben Weg geboten; das Forum war lediglich der Beweis.
Dies ist ein Fund aus dem Dependency-Auditing, der durch methodisches Nachverfolgen der Pipeline an Bedeutung gewann, und die Reihenfolge der Entdeckung ist entscheidend.
Das Team begann mit einer unscheinbaren Frage: Wo übergibt diese Anwendung Dateien, die sie selbst nicht versteht, an den Parser eines anderen? Beim Nachverfolgen der Upload-Verarbeitung von Discourse bemerkten sie den Umweg über FastImage zu ImageMagick bei HEIF – einen Format-Ausnahmezweig, den Prüfer überfliegen, weil er der Kompatibilität dient, nicht der Sicherheit. Anschließend baten sie ein KI-Modell, das installierte libheif-Paket im Discourse-Docker-Image zu untersuchen, und es meldete, dass bestimmte Fixes nie zurückportiert worden waren.
Das Modell erfand keinen Zero-Day; es fand einen tatsächlich ungepatchten, öffentlich committeten Bug und erkannte dessen sicherheitsrelevante Bedeutung. Die Schwachstelle war upstream „bekannt“ und downstream unsichtbar – die Aufgabe des Modells war es, diese Lücke zu bemerken.
Opus 4.8 erstellte daraufhin einen Exploit, der nur mit deaktiviertem ASLR funktionierte; wenige Stunden nach der Veröffentlichung von Opus 5 durch Anthropic erzeugte das neuere Modell einen funktionierenden Exploit, den das Team an die x86-64- und jemalloc-Konfiguration des Forums anpasste. Bis 06:00 UTC am 25. Juli hatten sie lokale RCE über einen Bild-Upload bestätigt.
Zuerst testeten sie gegen ihre eigene Discourse-Cloud-Instanz – als CTF-Ziel gerahmt, da das Modell sich weigerte, auf ein entferntes Produktionssystem zu zielen – und erst dann führten sie es gegen community.openai.com aus, gegen 10:00 UTC. Der letzte Akt: Der Codex eines Mitarbeiters, verbunden mit der GitHub-Organisation von OpenAI, wurde angewiesen, einen einzigen harmlosen Pull Request – #1186742 – im internen Monorepo zu öffnen. Es wurde kein Quellcode gelesen oder heruntergeladen.
Dann endeten die Tests.
Diese Zurückhaltung ist das Vorbild für die stärkste Wirkungsdemonstration, die keine sensiblen Daten berührt: ein einzelnes, offensichtlich harmloses Artefakt, erstellt im eigenen System der Wahrheit des Ziels – eine Behauptung über Zugriff, umgewandelt in einen Beweis für Zugriff.
Jede Schicht vertraute der Schicht darüber auf eine leicht andere Weise, und niemand war für die Grenze zwischen ihnen verantwortlich. Die Bildpipeline vertraute der Formaterkennung: Eine Datei, die sich als Foto ausgab, wurde an einen nativen Decoder weitergegeben, der mit den Privilegien der Anwendung lief. Die Distribution vertraute der upstream Commit-Message: Ein Fix ohne CVE-Nummer sah wie Routine-Wartung aus, daher erfolgte der Backport nie und die verwundbare Bibliothek wurde monatelang ausgeliefert.
Und die Identitätsschicht vertraute dem Vordereingang des Forums: Die SSO-Implementierung versäumte es, eine Forum-Anmeldung auf Zugriff auf Forumsebene zu beschränken, sodass die Kompromittierung des Forums zur Kompromittierung der gesamten Identität wurde. Das ist das Identity-Access-Management-Versagen im Kern dieser Geschichte – der Zugriff war eingegrenzt auf „diese Person hat bewiesen, wer sie ist“, nicht auf „diese Person hat bewiesen, wer sie ist, auf dieser Eigenschaft mit geringem Vertrauen, für diesen Zweck“.
Der unbequeme Teil: Nichts davon erforderte einen Zero-Day. Die Memory Corruption war upstream öffentlich committet; das SSO-Problem war eine Konfigurationsentscheidung. Neu war die Kombination und das Tempo. Das Epilog des Teams bringt es auf den Punkt: Sicherheit hat sich lange auf den stillen Schutz der Komplexität verlassen – Bugs konnten öffentlich sein, aber ihre Waffenisierung erforderte seltenes Können und Zeit. Wenn Modelle monatelange Exploit-Entwicklung auf Stunden verdichten, dünnt dieser Schutz aus, und Bedrohungsmodelle müssen einen Gegner einkalkulieren, der es sich leisten kann, alles auszuprobieren.
Verfolgen Sie jeden Parser, an den Ihr Ziel delegiert. Der Fund begann dort, wo der eigene Code der Anwendung endete: bei der Übergabe an ImageMagick und dann an libheif. Verfolgen Sie bei jeder Upload-Funktion die Datei über die Prüfungen der Anwendung hinaus und fragen Sie, welche native Bibliothek letztendlich die Bytes berührt. Format-Ausnahmezweige sind der Ort, an dem sich die interessanten Parser verstecken.
Suchen Sie nach nicht gekennzeichneten upstream Fixes. Ein Sicherheitsfix, der nie ein CVE erhalten hat, ist ein Backport, der nie stattfindet. Diffen Sie upstream Commits gegen die Versionen, die die Distributionen Ihres Ziels tatsächlich ausliefern, und behandeln Sie „upstream gefixt, nicht gekennzeichnet“ als aktive Schwachstellenklasse.
Behandeln Sie gemeinsames SSO als gemeinsames Vertrauen – und greifen Sie dann den schwächsten Beteiligten an. Wo immer eine Eigenschaft mit geringem Vertrauen Single Sign-On mit hochwertigen Konten teilt, wird die Sicherheitslage der Eigenschaft zur Sicherheitslage der Konten.
Testen Sie innerhalb des realen Artefakts. Die verwundbare Komponente lebte in der Debian-Schicht des Docker-Images, nicht im Anwendungscode von Discourse – ein Web-UI-Update hätte sie nie ersetzt. Definieren Sie Ihr Ziel als die auslieferbare Einheit (Container-Image, nicht Repository) und testen Sie das, was tatsächlich darin ausgeliefert wird.
Beweisen Sie die Wirkung, ohne die Kronjuwelen zu berühren. Der Pull-Request-Nachweis ist das Vorbild für eine verantwortungsvolle Demonstration maximaler Wirkung: ein unbestreitbares, reversibles Artefakt im System selbst, das exakt den behaupteten Zugriff erfordert – nichts mehr.
Bericht von Faizan Akhtar – The Cyber Security Researcher
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 16 • Originally published at faizanakhtarcyber.blogspot.com
Original research by the Hacktron AI team (Harsh Jaiswal, Mohan Pedhapati, Rahul Maini) — read the full writeup here: https://www.hacktron.ai/blog/hacking-openai · Researcher's profile: https://www.hacktron.ai
A single photo upload was the entire entry point into one of the most closely watched companies on the planet. In July 2026, three researchers from Hacktron AI turned a crafted HEIF image into remote code execution on OpenAI's community forum, then crossed a far more consequential boundary: an identity flaw in OpenAI's single sign-on let them take over the ChatGPT and Codex accounts of anyone who had merely signed into that forum, including employees. One employee's GitHub-connected Codex then opened a pull request inside OpenAI's private internal monorepo — proof of access delivered, no code read, testing stopped. This is my original analysis of their publicly disclosed research: how the two bugs were found, why the chain worked, and what hunters and defenders should take from it.
Harsh Jaiswal, Mohan Pedhapati and Rahul Maini — working as Hacktron AI — set out to probe the security posture of frontier AI companies and settled on OpenAI's community forum at community.openai.com, which runs on Discourse and offers "Sign in with OpenAI". What they found was not one vulnerability but two defects with a bridge between them: a memory-corruption flaw in the forum's image pipeline, and an SSO weakness that treated the forum's front door as a hallway into employees' accounts.
The timeline reads like a sprint. On July 23 they traced the forum's HEIF upload path to the vulnerable decoder; on July 24 they had a working exploit with ASLR disabled; on the morning of July 25 they had reliable code execution against the live forum, and that afternoon they opened the proof-of-access pull request and stopped testing — discovery to internal-repo access in under 72 hours. They reported the SSO-side finding through OpenAI's Bugcrowd program; OpenAI fixed it roughly 14 hours after submission and paid $6,500 for the OpenAI-side finding only (the forum itself was outside the bounty scope).
The forum-side issue went to Discourse's HackerOne program: received on a Saturday, answered on a Sunday, fixed on Monday. The writeup was published in mid-September 2026, alongside a wider campaign tracing the same decoder weakness across other platforms.
A heap buffer overflow in libheif, reachable through the forum's image pipeline. Discourse checks uploads with FastImage, but FastImage could not parse HEIF files, so those uploads were diverted to ImageMagick's magick command — which delegates HEIF decoding to the libheif library. That delegation exposed the raw libheif parser to attacker-controlled files, and the decoder contained a heap buffer overflow yielding out-of-bounds read and write primitives.
The supply-chain detail makes this case-study material: the faulty code had already been corrected upstream, but the commit was never flagged as a security fix and got no CVE. Treated as ordinary maintenance, it was never backported — the Discourse Docker image (Debian 12) shipped libheif 1.19.7 still vulnerable, and Debian 13 shipped 1.19.8 vulnerable too. A fix invisible to the people who decide what to backport is, from the attacker's perspective, no fix at all.
An OpenAI SSO identity flaw that crossed the trust boundary. The forum used "Sign in with OpenAI" through auth.openai.com. The second bug lived in how OpenAI's identity layer scoped that sign-in: with code execution on the forum, the researchers could take over the ChatGPT and Codex accounts of anyone signed in through that SSO flow — employees included — with no interaction from the victims. Because ChatGPT and Codex connect to services like GitHub, Slack and email, the blast radius extended into everything those connections could touch. The escalation is not Discourse-specific: any compromised service sharing that SSO arrangement would have offered the same path; the forum was merely the proof.
This is a dependency-auditing find elevated by methodical pipeline tracing, and the discovery order matters.
The team started with an unglamorous question: where does this application hand files it cannot understand to someone else's parser? Following Discourse's upload handling, they spotted the FastImage-to-ImageMagick detour for HEIF — a format-exception branch reviewers skim past because it exists for compatibility, not security. They then asked an AI model to inspect the installed libheif package inside the Discourse Docker image, and it reported that certain fixes had never been backported. The model did not invent a zero-day; it found a genuinely unpatched, publicly committed bug and recognized its security significance. The flaw was "known" to upstream and invisible to downstream — the model's job was noticing the gap.
Opus 4.8 then built an exploit that worked only with ASLR disabled; hours after Anthropic released Opus 5, the newer model produced a working exploit that the team ported to the forum's x86-64 and jemalloc configuration. By 06:00 UTC on July 25 they had confirmed local RCE through an image upload. They tested against their own Discourse Cloud instance first — framed as a CTF target, since the model refused to aim at a remote production system — and only then ran it against community.openai.com at around 10:00 UTC. The final act: an employee's Codex, connected to OpenAI's GitHub organization, was instructed to open a single harmless pull request — #1186742 — in the internal monorepo. No source code was read or downloaded. Then testing ended.
That restraint is the model for the strongest impact demonstration that touches no sensitive data: a single, obviously harmless artifact created inside the target's own system of record — a claim about access converted into evidence of access.
Every layer trusted the layer above it in a slightly different way, and nobody owned the boundary between them. The image pipeline trusted format detection: a file calling itself a photo was fed to a native decoder running with the application's privileges. The distribution trusted the upstream commit message: a fix without a CVE number looked like routine maintenance, so the backport never happened and the vulnerable library shipped for months.
And the identity layer trusted the forum's front door: the SSO implementation failed to constrain a forum sign-in to forum-level access, so forum compromise became identity-wide compromise. That is the identity access management failure at the heart of the story — access was scoped to "this person proved who they are", not to "this person proved who they are, on this low-trust property, for this purpose".
The uncomfortable part: nothing here required a zero-day. The memory corruption was publicly committed upstream; the SSO issue was a configuration decision. What was new was the combination and the speed. The team's epilogue says it plainly: security has long relied on the quiet protection of complexity — bugs might be public, but weaponizing them demanded rare skill and time. When models compress months of exploit development into hours, that protection thins, and threat models must price in an adversary who can afford to try everything.
Map every parser your target delegates to. The find began where the application's own code ended: at the handoff to ImageMagick and then libheif. For every upload feature, trace the file past the application's checks and ask which native library eventually touches the bytes. Format-exception branches are where the interesting parsers hide.
Hunt unflagged upstream fixes. A security fix that never got a CVE is a backport that never happens. Diff upstream commits against the versions your target's distributions actually ship, and treat "fixed upstream, unflagged" as a live vulnerability class.
Treat shared SSO as shared trust — then attack the weakest party. Wherever a low-trust property shares single sign-on with high-value accounts, the property's security posture becomes the accounts' security posture.
Test inside the real artifact. The vulnerable component lived in the Docker image's Debian layer, not in Discourse's application code — a web-UI update would never have replaced it. Scope your target as the deployable unit (container image, not repo) and test what actually ships inside it.
Prove impact without touching the crown jewels. The pull-request proof is the model for responsible maximum-impact demonstration: an undeniable, reversible, in-system artifact requiring exactly the access claimed — nothing more.
Report by Faizan Akhtar — The Cyber Security Researcher