Een recente beveiligingscase laat zien hoe snel digitale ketens gevaarlijker worden zodra meerdere componenten samenkomen. Onderzoekers van Hacktron gebruikten AI om een werkende aanval te bouwen via Discourse, de forumsoftware achter de community van OpenAI. Vervolgens koppelden ze die aanval aan een aparte fout in het sign-in proces, waardoor ze toegang konden krijgen tot accounts die aan ChatGPT en Codex zijn gekoppeld — en uiteindelijk interne code-repositories konden benaderen.
Wat dit extra relevant maakt: het begon niet bij een “grote” kwetsbaarheid die iedereen al kent, maar bij een bug die eerder al was opgelost in een afhankelijkheid, zonder dat dit als security-issue was opgepikt. Daardoor bleef de patchcyclus uit.
De aanvalsketen: van fotoupload tot code-toegang
De onderzoekers kozen als startpunt de OpenAI-community op community.openai.com. Deze draait op Discourse. In Discourse zitten ingebouwde controles voor afbeeldingen, maar die ondersteunden bepaalde bestandsformaten niet goed.
Concreet: uploads in HEIC/HEIF kwamen terecht in een afbeeldingsverwerkingstraject waarbij ImageMagick betrokken was. Daar werd een onveiligheid in de gebruikte decoding-bibliotheek libheif zichtbaar. Hacktron stelt dat deze onderliggende bug al eerder upstream was gefixt (ruim een jaar), maar omdat het nooit als security-issue werd gemarkeerd, kreeg het geen CVE en werd er geen standaard patchactie op getriggerd.
Met andere woorden: het gat bestond nog doordat de fix niet tijdig (of niet volledig) terechtkwam in de praktijklaag van het forum.
AI hielp bij het betrouwbaar maken van de exploit
In plaats van alleen een concept te bewijzen, moest de aanval ook “stabiel” worden in de echte omgeving. Hacktron gaf aan dat het meerdere pogingen vergde om de exploit betrouwbaar te krijgen.
Daarbij werd Claude ingezet om een werkend exploit-pad te bouwen. Voor de uitvoering spraken de onderzoekers over gebruik van versies van Claude (onder andere Opus 4.8 en Opus 5). Het resultaat: remote code execution (RCE) die eerst tegen een test-Discourse-omgeving werd beproefd en daarna ook op het forum zelf werd toegepast.
Dat RCE het startpunt was, is essentieel: daarmee verschuift het probleem van “alleen” een kwetsbaarheid in afbeeldingsverwerking naar een situatie waarin de aanvaller controle kan krijgen over systeemlogica of processen onder de applicatielaag.
Waarom sign-in zo belangrijk werd: permissies voor API-toegang
De tweede schakel in de keten zat niet in Discourse zelf, maar in het sign-in mechanisme van OpenAI. Volgens Hacktron — en ook als door OpenAI in de reactie gespecificeerd — gaat het om een apart probleem.
De sign-in tokens die voor de community werden aangemaakt, bleken excessieve rechten te kunnen bevatten. Hierdoor kon een aanvaller, nadat hij of zij via de forumomgeving code-executie had verkregen, de controle over relevante sessies en daarmee ChatGPT- en Codex-accounts overnemen.
Hacktron beschrijft dat dit theoretisch tot brede gevolgen kon leiden: gebruikers of medewerkers die zich in die periode op het forum aanmeldden, zouden — totdat de kwestie was verholpen — hun accounts kunnen zien aangetast.
Omdat accounts vaak gekoppeld worden met externe diensten, wordt het dreigingsbeeld groter. In het rapport wordt als voorbeeld genoemd dat de impact in theorie kon doorlopen naar diensten zoals GitHub, Slack en e-mail, al is niet bevestigd dat die toegang daadwerkelijk is gerealiseerd voor alle genoemde systemen.
Wat konden de onderzoekers aantonen?
Hacktron wilde aantonen dat het echt mogelijk was om verder te komen, maar gaf ook aan dat ze bij de demonstratie geen interne code hoefden te “lezen”. Ze namen een OpenAI-medewerkersaccount over dat een Codex-integratie had die gekoppeld was aan de GitHub-organisatie van OpenAI.
Vervolgens gebruikten ze die toegang om een pull request te openen in een intern repository. Daarbij stopten ze het testen, om niet verder te gaan dan noodzakelijk. Volgens de onderzoekers was de pull request specifiek bedoeld om bijvoorbeeld een README-bestand te wijzigen (dus geen omvangrijke uitlezing van broncode).
OpenAI bevestigde in zijn eigen beoordeling dat er beperkt werd gelezen uit metadata van private repositories en commits, waarna de pull request werd ingediend. Daarna werd verder onderzoek afgeremd.
Slak als potentiële extra route — maar zonder bewijs van berichteninzicht
Hacktron benoemde ook Slack als een dienst die via gekoppelde accounts theoretisch bereikbaar kon worden. OpenAI stelt daartegenover dat Hacktron niet heeft geverifieerd of er daadwerkelijk toegang was tot Slack-berichten van medewerkers.
Dit onderscheid is belangrijk voor het risicobeeld. Niet elke “mogelijkheidsketen” leidt tot bewezen impact. Toch blijft het signaal duidelijk: wanneer account-koppelingen bestaan, kan een accountovername in de praktijk meer om zich heen grijpen dan alleen de primaire app.
Rapportage, fixes en tijdlijn van de respons
Hacktron rapporteerde de accountovername-kwestie via Bugcrowd. OpenAI bevestigde dat er ongeveer 14 uur later een fix werd doorgevoerd.
OpenAI richtte de mitigatie op het beperken van de permissies van community sign-in tokens en het intrekken van aangetaste tokens en sessies. Dat betekent: zelfs als iemand eerder misbruik had geprobeerd, zou hergebruik minder kansen krijgen.
Voor de Discourse-zijde (de libheif-gerelateerde bug) liep de melding via HackerOne. Hacktron geeft aan dat Discourse een oplossing al binnen twee dagen gereed had. Daarnaast werd er een extra beschermingslaag toegevoegd: sandboxing voor beeldverwerking. Daarna publiceerde Discourse ook een security advisory.
Wat je hier vandaag uit kunt halen voor je securityaanpak
Los van deze specifieke case zitten er een paar lessen in die vrijwel elke organisatie met webapplicaties, forums of community-platformen herkent.
- Afhankelijkheden blijven risico’s dragen. Zelfs als een bug upstream wordt opgelost, kan het in de keten nog lang misgaan.
- AI maakt exploits sneller “operationeel”. Dat wil niet zeggen dat elke aanval daarmee lukt, maar het verlaagt de drempel om iets van proof-of-concept naar werkbare exploit te brengen.
- Token-permissies zijn geen detail. Als sign-in tokens meer rechten hebben dan nodig, kan accountovername leiden tot API-toegang en kettingimpact.
- Gekoppelde services vergroten de impact. Denk vooraf na over welke verbindingen je gebruikers- en medeaaccounts kunnen doorgeven.
Als je dit naast andere incidenten uit de sector legt, zie je dat het patroon vaak terugkomt: kwetsbaarheden in één laag (bijvoorbeeld een component van een platform) worden pas écht gevaarlijk wanneer ze worden gecombineerd met fouten in authenticatie, autorisatie of integraties. Je kunt dit herkennen in eerdere supply chain en exploit-gevallen die ook laten zien hoe snel impact kan oplopen.
Voor aanvullende context rond supply chain en misbruik in softwareketens kun je bijvoorbeeld ook lezen over de supply chain aanval waarbij malware op 100.000 websites werd gemeld.
Conclusie: één forumfout werd een pad naar interne repositories
De kern van het verhaal is helder: AI-exploit via Discourse was geen eindpunt, maar het begin van een aanvalsketen. Door een kwetsbaarheid in afbeeldingsverwerking te combineren met een aparte fout in OpenAI’s sign-in permissies, konden de onderzoekers accounts overnemen en aantonen dat interne GitHub-repositories te bereiken zijn.
De respons volgde vrij snel: token-permissies werden aangescherpt en sessies werden ingetrokken, terwijl Discourse ook aanvullende mitigaties toepaste met sandboxing. Voor organisaties is dit een sterke reminder om zowel de technische keten (dependencies) als de autorisatiekant (tokens en rechten) serieus door te rekenen — zeker wanneer externe platforms en gekoppelde diensten samenkomen.
Wil je meer lezen over aanvallen die ook draaien om softwarecomponenten en misbruik van platformroutes? Bekijk dan zeker ook hoe stealer-malware via npm-pakketten en moderne tooling het gemunt heeft op toegang.
Bron: https://www.securityweek.com/ai-built-exploit-and-sign-in-flaw-opened-path-to-internal-openai-code/
