Een recente security-onderzoekscasus laat zien hoe snel echte impact kan ontstaan wanneer meerdere zwakheden elkaar versterken. In een gecontroleerde test gebruikten onderzoekers Claude Opus 5 om via twee gekoppelde fouten uiteindelijk toegang te krijgen tot ChatGPT- en Codexaccounts van OpenAI-medewerkers. Belangrijk: het ging om verantwoord onderzoek, met melding, bewijs via een onschadelijke pull request en daarna stoppen.
Toch is de les breed. Niet alleen de AI hielp bij het vinden van een exploit; vooral de combinatie van identity (aanmeldlogica/SSO) en image-verwerking bepaalde hoe ver de keten reikte.
Wat er in de test gebeurde
De onderzoekers van Hacktron rapporteerden dat ze met Claude Opus 5 twee afzonderlijke zwakheden aan elkaar konden koppelen. Ze startten bij een bug in software die de publieke helpforum-omgeving ondersteunt, waarna een volgende zwakte in de login-inrichting van OpenAI toegang mogelijk maakte.
Volgens Hacktron leidde dat tot accountovername van enkele medewerkers, waarna ze ook een interne code-repository konden benaderen. Het bewijs werd geleverd met een onschadelijke pull request. Er werd geen broncode gelezen, geen commits samengevoegd en er is geen klantdata benaderd.
De tijdlijn toont bovendien hoe efficiënt de keten was: de onderzoekers zeggen dat de betrokken interne toegang binnen minder dan 72 uur vanaf de eerste aanpak gerealiseerd werd. OpenAI bevestigde een fix zo’n 14 uur na de melding en betaalde een bounty van $6.500.
Waarom een forumbug ineens “bij medewerkers” uitkomt
De kern van het scenario zat niet in het forum zelf, maar in de manier waarop aanmelden was ingericht. Het publieke forum bood een optie als “Sign in with OpenAI”, hetzelfde type single sign-on dat ook intern bij andere OpenAI-diensten wordt gebruikt.
Toen de onderzoekers controle kregen over de forumserver, kon de gedeelde login doorwerken richting ChatGPT en Codex. Daardoor hoefden slachtoffers niet zelf iets te doen: hun bestaande accountverbinding werd in de keten het toegangspunt.
Hacktron beschrijft het dan ook als een identity-probleem in de koppeling van diensten. Als dezelfde SSO door meerdere applicaties loopt, kan een inbraak op het “lagere vertrouwensniveau” (zoals een publiek forum) theoretisch overslaan naar “hogere vertrouwensniveaus” (zoals interne tools).
De technische start: HEIF/HEIC en libheif
De eerste schakel in de keten kwam voort uit een afbeeldingsverwerking. Het forum draaide op Discourse. Wanneer gebruikers geüploade afbeeldingen uploaden in HEIC/HEIF-formaat, geeft Discourse dit door aan een beeldverwerkingsketen met ImageMagick en vervolgens de libheif-bibliotheek.
In libheif werd een kwetsbaarheid misbruikt. De openbare advisering rond de issue beschrijft de uitkomst als een remote code execution-risico (met een hoge score), terwijl andere publieke records de nadruk leggen op een out-of-bounds read die kan leiden tot crashen of het uitlekken van nabije geheugeninhoud.
Volgens de onderzoekers maakte het uitlekken van geheugen het mogelijk om een veelgebruikte bescherming, ASLR, te omzeilen. Door die geheugenproblemen te combineren met het uiteindelijke exploit-proces konden ze volgens hun rapport de crash transformeren tot werkende code-uitvoering op de forumserver.
Fixen kostte niet alleen softwarewerk, maar ook “welke build draait er”
Het ingewikkelde deel in dit verhaal zit in het verschil tussen “er bestaat al een fix” en “jouw omgeving draait de fix ook daadwerkelijk”. Upstream is libheif aangepast in versie 1.22.0 (fix beschikbaar sinds mei 2026).
Maar toen de onderzoekers in juli keken, bleek de server die het forum gebruikte een oudere library-versie te hebben: libheif 1.19.7. De omgeving was gebaseerd op Debian 12, en blijkbaar had die distributie de aanpassing nog niet (voldoende) doorgezet in de image waarop de forumomgeving draaide.
Dit punt is extra relevant voor organisaties die zelf Discourse hosten. Een web-interface update alleen kan onvoldoende zijn als onderliggende libraries in een image of build niet vervangen worden. Hacktron noemt daarom een herbouw op de nieuwste (gepatchte) image als aanpak.
Claude Opus 5 als versneller: van uren naar “binnen enkele uren”
Naast de technische kwetsbaarheden is er nog een tweede verhaal: de rol van Claude Opus 5. De onderzoekers probeerden eerst een eerdere versie van Anthropic’s model (Claude Opus 4.8). Daarbij kostte het opzetten van een werkend exploitproces meerdere sessies, vooral omdat standaard geheugenbeschermingen zoals ASLR de route bemoeilijkten.
Toen ze overstapten op Claude Opus 5 (beschikbaar gekomen op de avond van 24 juli), maakte het model in een nieuwe sessie volgens Hacktron veel sneller een werkende exploit mogelijk, binnen enkele uren.
Het model had ingebouwde safeguards om het schrijven van exploitcode voor echte doelen te beperken. De onderzoekers omzeilden die beperkingen door het model te richten op hun eigen testserver en het proces te laten draaien in een geautomatiseerde oefenloop, vergelijkbaar met een “capture-the-flag”-achtige setting. Ze benadrukken daarbij wel dat het geen volledig hand-off proces was: menselijke sturing bleef nodig.
Hoe ver had de keten kunnen gaan?
De onderzoekers geven aan dat dezelfde instaproute potentieel veel verder had kunnen reiken. Medewerkers koppelen ChatGPT en Codex namelijk aan andere services. Als diezelfde login vervolgens doorwerkt naar platformen die ook SSO vertrouwen, dan kan een inbraak op het forum theoretisch uitbreiden naar zaken als GitHub, Slack en e-mail.
In deze test werd die uitbreiding niet benut. Toch is het scenario precies het soort “brede impact”-denken dat security teams nodig hebben: niet alleen “welke kwetsbaarheid” telt, maar ook “welke trust-relaties” bestaan er tussen systemen.
Praktische aandachtspunten voor je eigen omgeving
Los van de specifieke naam van de forumsoftware of de betrokken partijen, zijn er drie concrete thema’s: patching van image-verwerking, beperkingen op het verwerken van onbetrouwbare bestanden en het herzien van SSO-trust.
1) Update en verifieer library-versies
Als je software HEIF/HEIC/AVIF afbeeldingsbestanden verwerkt via libheif (direct of indirect), kijk dan niet alleen naar “geüpdatete app-versie”, maar ook naar welke library/build er echt draait. Hacktron noemt bijvoorbeeld dat een herbouw op een gepatchte image vereist kan zijn.
Dit sluit aan bij het bredere idee dat een CVE-patch pas waarde heeft als de runtime daadwerkelijk de nieuwe code gebruikt. Eerder schreven we op onze site ook over het belang van bewijs om te toetsen of een CVE in jouw situatie echt misbruikbaar is (en niet alleen theoretisch). Lees bijvoorbeeld Bron: https://thehackernews.com/2026/09/claude-opus-5-helped-researchers-take.html
