Hacking OpenAI

Introductie

Op 25 juli 2026 hebben we twee kritieke kwetsbaarheden gekoppeld om de ChatGPT-accounts van meerdere medewerkers van OpenAI te compromitteren. Met deze accounts konden we toegang krijgen tot interne OpenAI-repositories en potentieel tot vele andere connectoren.

Om te bewijzen dat we daadwerkelijk toegang hadden gekregen, zonder onszelf bloot te stellen aan gevoelige informatie, gebruikten we de Codex van een medewerker om een pull request (PR #1186742) te openen in de interne monorepo van OpenAI (openai/openai).

De exploit-keten

  • libheif (Beelddecoder) → Debian (Ontbrekende security backport) → ImageMagick (Maakt gebruik van libheif) → Discourse (Afbeelding-uploads) → OpenAI forum (community.openai.com) → OpenAI SSO Identity flaw → ChatGPT / Codex (Accounttoegang) → GitHub (Verbonden integratie) → Interne repos (OpenAI).

Tot twee maanden geleden kon elke gebruiker of OpenAI-medewerker die inlogde op het eigen helpforum van OpenAI (community.openai.com) zijn ChatGPT- en Codex-accounts overgenomen zien worden. Omdat mensen diverse diensten kunnen koppelen aan Codex en ChatGPT, was de reikwijdte van wat we theoretisch konden bereiken enorm, inclusief GitHub, Slack en e-mails.

Het volledige traject, van de eerste ontdekking tot de toegang tot de OpenAI-repo, nam minder dan 72 uur in beslag.

We hebben de initiële kwetsbaarheid onmiddellijk gemeld bij OpenAI en Discourse en hebben met hen samengewerkt om de patch te coördineren. We waarderen hun aandacht voor detail en de snelle oplossing van dit probleem. OpenAI heeft ons een bounty van $ 6.500 betaald.

Tijdlijn van de disclosure

  • 25 juli 2026, 05:00–06:00 UTC: Initiële vondst

Het HacktronAI-team verkreeg remote code execution (RCE) en administratieve toegang tot de Discourse-omgeving op community.openai.com.

  • 25 juli 2026, 08:00–10:00 UTC: Bugcrowd-melding

Na het bevestigen van de impact over verschillende producten, coördineerde het team intern het proces van verantwoorde disclosure en diende een rapport in via het Bug Bounty-programma van OpenAI op Bugcrowd.

  • 25 juli 2026, 13:30–15:30 UTC: Toegang tot accounts van OpenAI-medewerkers & Proof of Concept

Om de praktische impact aan te tonen, maakten we een onschadelijke proof-of-concept pull request aan in de interne monorepo van OpenAI (link verwijderd op verzoek van OpenAI). We hebben de Bugcrowd-melding bijgewerkt, contact opgenomen met vrienden bij OpenAI via Twitter/X om hen direct te informeren, en alle verdere tests gestaakt rond 15:30 UTC.

  • 25 juli 2026, 22:49:45 UTC: Fix bevestigd door OpenAI

OpenAI reageerde op het rapport en bevestigde dat het probleem was opgelost, ongeveer 14 uur na de initiële indiening.

  • 25 juli 2026: Discourse gemeld via HackerOne

We hebben een rapport ingediend bij Discourse via hun HackerOne-programma.

  • 26 juli 2026: Reactie van Discourse

Discourse reageerde op het rapport op zondag.

  • 27 juli 2026: Fix van Discourse gereed

Discourse had op maandag een fix klaar en voegde sandboxing voor beeldverwerking toe als 'defense in depth'.

  • 28 juli 2026: Discourse Advisory gepubliceerd

Discourse publiceerde GHSA-vhm9-85gw-x335 met richtlijnen voor de patch en herbouw.

  • 1 september 2026: OpenAI beloont met $ 6.500 bounty en markeert als opgelost

OpenAI merkte op dat testen tegen de Discourse-hosted community.openai.com expliciet was uitgesloten van hun bug bounty-programma, maar dat de beloning betrekking heeft op de bevindingen aan de OpenAI-zijde, niet op de acties tegen Discourse.

Achtergrond

Enige tijd geleden begon ons team bij Hacktron, geleid door Harsh Jaiswal samen met Mohan Pedhapati en Rahul Maini, onderzoek te doen naar vooraanstaande AI-bedrijven om beveiligingskwetsbaarheden te vinden. Dit leidde tot de ontdekking van een SSO-misconfiguratie in de identiteitsinfrastructuur van OpenAI en een libheif RCE in het door OpenAI gebruikte communityforum.

We hebben dit onderzoek sindsdien uitgebreid naar HEIF Heist, een maandenlang onderzoek waarbij libheif werd getraceerd in Slack, Meta, GitHub Enterprise, Ruby on Rails en Node.js-frameworks zoals Next.js, Astro en Gatsby. Een verrassende hoeveelheid veelgebruikte software is afhankelijk van deze ene bibliotheek voor beeldverwerking.

Indien uw applicatie door gebruikers gecontroleerde afbeeldingen verwerkt en .heic/.heif/.avif afbeeldingen accepteert, is de kans groot dat deze is getroffen.

Het hacken van community.openai.com

Waarschuwing: Patch-mededeling
Als u Discourse zelf host, herbouw dan nu uw installatie. Oudere Docker-images kunnen een kwetsbare libheif-afhankelijkheid bevatten die code-uitvoering via een afbeelding-upload mogelijk maakt. Voer git pull uit, gevolgd door ./launcher rebuild app vanuit /var/discourse; een update via de webinterface alleen vervangt mogelijk niet de onderliggende image. Discourse-hosted klanten zijn reeds gepatcht. Zie de security advisory.

OpenAI gebruikt Discourse voor hun forum en staat "Sign in with OpenAI" toe via auth.openai.com. Na een grondige analyse van de diensten en infrastructuur van OpenAI, hadden we reden om te geloven dat het compromitteren van het forum een weg kon openen naar bredere OpenAI-diensten via deze identiteitsstroom. Om deze hypothese te testen, hadden we eerst remote code execution nodig op een OpenAI-dienst, zoals het Discourse-communityforum.

Hoewel de Discourse-applicatie zelf geen makkelijk doelwit is, dachten we dat we een afhankelijkheid (dependency) konden aanvallen.

Heap buffer overflow in libheif

Op 23 juli begonnen we met het beoordelen van de image-upload pipeline van Discourse en ontdekten we dat HEIC- en HEIF-bestanden een ongebruikelijk pad volgden. Discourse gebruikte normaal gesproken FastImage voor beeldcontroles, maar omdat FastImage geen HEIF ondersteunde, werden deze bestanden doorgegeven aan het magick-commando van ImageMagick voor conversie. Dit stelde de onderliggende libheif-parser direct bloot aan bestanden die door een aanvaller worden gecontroleerd.

We startten een Opus 4.8-sessie met de Discourse Docker-image en vroegen deze om het geïnstalleerde libheif-pakket te inspecteren op beveiligingsproblemen. Na enige tijd ontdekte het model dat bepaalde beveiligingsfixes niet waren teruggepoort (back-ported) naar het libheif-pakket. Dit maakte een heap buffer overflow mogelijk, leidend tot OOB (Out-Of-Bounds) R/W-primitieven tijdens het decoderen van HEIC.

Interessant genoeg was de kwetsbare code het jaar ervoor upstream gewijzigd, maar de commit was niet gedocumenteerd als een beveiligingsfix en kreeg geen CVE. Dit is mogelijk de reden waarom Debian 12 en 13 de relevante security backports niet tijdig hebben ontvangen. Omdat de Docker-image van Discourse was gebaseerd op Debian 12, werd de kwetsbare libheif versie 1.19.7 geïnstalleerd. Zelfs Debian 13 leverde op dat moment nog de kwetsbare versie 1.19.8. Sindsdien heeft Debian op 8 augustus 2026 een security-update voor Debian 13 gepubliceerd.

Op 24 juli gebruikten we Opus 4.8 om een werkende ImageMagick/libheif code-execution exploit te ontwikkelen met ASLR uitgeschakeld. We startten vervolgens verschillende aparte sessies om het betrouwbaar te maken tegen de standaardconfiguratie van Discourse met ASLR ingeschakeld, maar dit leverde niets op.

Release van Opus 5

Diezelfde avond bracht Anthropic Claude Opus 5.5 uit. We startten een nieuwe sessie, die binnen 3 uur een werkende ARM64-exploit produceerde voor een lokale Mac. Vervolgens vroegen we het model om de exploit te porten naar de x86-64 omgeving en jemalloc-configuratie die door Discourse wordt gebruikt.

Tegen 6:00 uur op 25 juli hadden we lokale RCE bevestigd via een afbeelding-upload. We plaatsten Claude vervolgens in een autonome /goal loop tegen onze eigen Discourse Cloud-instantie, geproxied via rce.ee/ctf-forum om het te laten lijken op een CTF-doelwit, aangezien Opus weigerde exploits te schrijven voor remote-instanties.

Toen we om 10:00 uur opnieuw controleerden, had de agent RCE bereikt op Discourse Cloud en toegang aangetoond door /etc/hosts te lezen. Met het gegenereerde exploit-script lukte het ons RCE te verkrijgen op de instantie van OpenAI.

Nadat we onze hypothese hadden bevestigd dat het mogelijk was om ChatGPT/Codex-accounts van actieve forumleden over te nemen zonder interactie, stuurden we direct ons rapport naar OpenAI. We namen vervolgens het account van een OpenAI-medewerker over, wiens Codex was verbonden met de GitHub-organisatie van OpenAI. Om de impact aan te tonen zonder daadwerkelijk interne code in te zien, stuurden we een prompt naar het Codex-account van deze medewerker om een PR voor ons te openen in de interne monorepo van OpenAI. Daarna stopten we met alle verdere tests.

We hebben de BugCrowd-melding bijgewerkt met het bewijs van de impact en de security-afdeling van OpenAI gealarmeerd. Ook hebben we een rapport voorbereid voor Discourse en dit gemeld via hun HackerOne-programma. Discourse ontving het rapport op zaterdag, reageerde op zondag en had op maandag een fix klaar. Ze startten daarnaast direct met het sandboxen van ImageMagick.

We willen benadrukken dat de kwetsbaarheid om te escaleren niet specifiek is voor Discourse. Het is een OpenAI SSO-probleem dat de compromittering van het forum veranderde in toegang tot ChatGPT en Codex. Als enige first-party of third-party OpenAI-dienst die gebruikmaakt van de OpenAI SSO zou worden gecompromitteerd, zou dit tot dezelfde toegang leiden; Discourse was slechts één manier om dit te bewijzen.

Kosten van het vinden van deze kwetsbaarheden

De hack van Discourse en OpenAI nam een paar dagen in beslag voor een agent, en slechts een paar uur aan menselijke tijd. Het gehele HEIF Heist-onderzoeksproject gericht op Slack, Zoom, Meta en anderen nam twee maanden in beslag, kostte in totaal minder dan $ 3.000 aan tokens en werd uitgevoerd door drie onderzoekers. Het aanpassen van de exploit voor elk nieuw bedrijf duurde meestal slechts één of twee dagen.

We merkten dat elk nieuw model steeds krachtiger wordt, zoals blijkt uit de Discourse-exploit in dit rapport. Opus 4.8 had moeite in verschillende sessies om een werkende exploit met ASLR ingeschakeld te produceren. Binnen enkele uren na de release van Opus 5 gaven we het model hetzelfde probleem en slaagde het. In de bredere campagne zagen we een andere duidelijke sprong van Opus 5 naar GPT-5 Sol, wanneer we de kwetsbaarheid moesten exploiteren zonder iets te weten over het doelsysteem, behalve dat het kwetsbaar was.

Voor elk doelwit begon het testen met een afbeelding-upload. Vanaf dat punt zetten we memory corruption om in een betrouwbare memory leak of shell, meestal zonder de exacte libheif-versie, libc-versie of deployment-omgeving te kennen. De AI begon bijna blind en paste de exploit voor elk bedrijf binnen één of twee dagen aan. We weten van geen enkel bedrijf dat de activiteit heeft gedetecteerd, behalve Shopify, zelfs nadat er duizenden afbeeldingen waren verzonden en hun image-processors herhaaldelijk crashten.

Wanneer de code-uitvoering landde in een sandbox of beperkte omgeving, hielpen de modellen ook bij privilege escalation, lateral movement en het omzeilen van bestaande verdedigingen. Dit was geen volledig autonome hacking, en deskundige menselijke begeleiding bleef belangrijk, maar de hoeveelheid werk die een klein team kon verrichten, nam dramatisch toe.

Epiloog

Software heeft lange tijd geprofiteerd van een soort "security through complexity". De code en zelfs de kwetsbaarheid konden openbaar zijn, maar het omzetten van een bug in een betrouwbare exploit vereiste nog steeds zeldzame expertise, aanzienlijke tijd en kennis van de doelomgeving. Bekende memory corruption-kwetsbaarheden waren duur om operationeel te maken, terwijl zero-days grotendeels gereserveerd waren voor de hoogst gewaardeerde doelwitten.

Dit was nooit een echte beveiligingsgrens, maar in de praktijk beschermde het gewone bedrijven tegen softwarekwetsbaarheden. AI verwijdert die bescherming door deze schaarse expertise om te zetten in compute. Werk dat ooit een goed gefinancierd team en maanden aan inspanning vereiste, kan nu worden samengeperst tot dagen.

Beveiligingsaannames moeten worden bijgewerkt aan de mogelijkheden van aanvallers. Een realistisch dreigingsmodel moet rekening houden met de economie van exploitatie van vandaag, in plaats van te vertrouwen op verouderde aannames over wie geavanceerde aanvallen kan uitvoeren.

De missie van Hacktron is om het internet veiliger te maken door kwetsbaarheden in breed vertrouwd software te vinden en te elimineren voordat kwaadaardige actoren dat doen. We zetten dit onderzoek voort bij frontier labs en andere internetkritische systemen.

Betrokken versies en patches

HEIF Heist is niet gebonden aan één enkele versie. Het richt zich op een heel ecosysteem van kwetsbaarheden over meerdere release-families (bijv. 1.19.x, 1.20.x, 1.22.x, 1.23.x). Elke implementatie die de nieuwste upstream security patches mist, is potentieel kwetsbaar.

  • Update upstream: Installeer de nieuwste security-patched libheif en libde265 pakketten via het security-kanaal van uw distributie of een upstream release. Per 14 september 2026 is de nieuwste upstream libheif security release v1.23.4. Distributiepakketten kunnen backported fixes bevatten onder een ouder upstream versienummer, dus controleer ook de package security advisory.
  • Defense in depth: Gezien de complexiteit van het ISO base media file format en het tempo van decoder-updates, zijn toekomstige memory-safety flaws waarschijnlijk. Productie-architecturen zouden onvertrouwde HEIF/AVIF-decodering moeten uitschakelen waar dit niet nodig is, of image-processing pipelines moeten isoleren in geharde, efemere sandboxes. De beveiligingspolicy van ImageMagick ondersteunt het beperken van geaccepteerde formaten en resource-gebruik.

Erkenningen

Wij danken Sudanshu Rajhbhar voor technische assistentie, en Zayne Zhang, Fabian Faessler, Robert Chen en Jessica Ruan voor het nalezen, reviewen van concepten en het geven van feedback die dit artikel heeft verbeterd.

Referenties

[1] xkcd #2347: Dependency [2] Discourse: Support for HEIC images [3] libheif: simplify overlay overlap area computation [4] Debian DSA-6417-1: libheif security update [5] Anthropic: Introducing Claude Opus 5 [6] RAND: A Playbook for Securing AI Model Weights [7] libheif v1.23.4 security maintenance release [8] ImageMagick Security Policy