Hacktron: lekken, OpenAI-accounts en bug bounty

Status: 10 oktober 2026

Onderzoekers van Hacktron combineerden een fout in de beeldverwerking in libheif met een configuratieprobleem bij SSO-aanmelding en kregen via een forum toegang tot accounts van OpenAI-medewerkers (verslag van 13-09-2026). Deze casus laat zien waarom de beveiliging van Single Sign-On (SSO) moet worden beoordeeld op basis van toegangsrechten en vertrouwensgrenzen, en niet op basis van hoe belangrijk één individuele dienst lijkt. In de reeks AI-cases staat hier de vraag centraal: welke deuren kan een ogenschijnlijk secundaire integratie openen buiten het eigen systeem?

Tijdlijn van de gebeurtenissen

1. 25-07-2026 - OpenAI bevestigt de fix; Hacktron, 13-09-2026.
2. 28-07-2026 - Bericht van Discourse; Hacktron, 13-09-2026.
3. 01-09-2026 - Uitbetaling van de beloning; Hacktron, 13-09-2026.

Cijfers en context

Omrekening op basis van de ECB-referentiekoers van 12-10-2026 (1 EUR = 1,1181 USD); bron: ECB.

Een PR, oftewel een pull request, is een voorstel tot codewijziging dat ter beoordeling wordt ingediend. In dit onderzoek fungeerde het louter als bewijs van toegang. Het openen van zo’n voorstel betekent uiteraard niet dat de code ook daadwerkelijk naar productie is uitgerold of dat eindgebruikers erdoor zijn geraakt.

Het verloop: een keten van zwakheden, geen autonome AI-aanval

De onderzoekers maakten bij hun werkzaamheden gebruik van Claude-modellen (Hacktron, 13-09-2026). Ook CERT-EU maakte melding van de publieke verslagen en de toegekende beloning (oktober 2026).

De volgorde van handelen is hier cruciaal: het ontdekken van de kwetsbaarheid, het aantonen van de toegang, het onmiddellijk staken van de proeven en een verantwoorde melding. Zo’n zogeheten ‘proof of access’ dient uitsluitend om aan te tonen dat een beveiligingsbarrière is doorbroken. Het is allerminst synoniem met het daadwerkelijk misbruiken van alle hypothetische mogelijkheden die uit die positie zouden kunnen voortvloeien. Daarom moeten feitelijke bevindingen strikt gescheiden blijven van speculaties over eventuele gevolgschade.

Evenzeer is het belangrijk om AI-ondersteuning te onderscheiden van eigen initiatief en regie. Een taalmodel kan een onderzoeker assisteren bij analyse en codewerk, maar de inzet van zo’n tool bewijst geenszins dat het model zelf doelen selecteerde, de scope bepaalde of beslissingen nam over de vervolgstappen. Door het volledige resultaat aan AI toe te schrijven, zouden menselijke keuzes en verantwoordelijkheden onterecht uit beeld verdwijnen.

Analyse: vertrouwensgrenzen zijn belangrijker dan het type applicatie

Een extern forum wordt vaak gezien als een onschuldig randverschijnsel van een digitaal platform. Bij een beveiligingsanalyse zegt dat label echter bijzonder weinig. De werkelijke impact van een toepassing hangt af van welke identiteiten zij erkent, welke permissies zij toekent en naar welke interne systemen haar koppelingen leiden. Een secundaire dienst mag nooit automatisch een hoog vertrouwensniveau erven puur omdat dat handig is voor het gebruiksgemak.

SSO vergroot het gebruiksgemak bij het inloggen aanzienlijk, maar vervangt nooit een doordachte architectuur van permissies en vertrouwensgrenzen. Een gedeelde identiteit betekent immers niet automatisch gedeelde rechten. Bij de evaluatie van een integratie moet je je dus niet alleen afvragen of een gebruiker soepel kan inloggen, maar vooral wat de externe dienst mag doen met het verkregen vertrouwen en waar dat vertrouwen moet ophouden.

Iedere koppeling heeft een duidelijke eigenaar nodig. Afzonderlijke beheerders voor een forum, voor centrale gebruikersaccounts en voor interne werknemerssystemen volstaan niet als niemand toezicht houdt op de interactie daartussen. Juist op het snijvlak van diensten moet helder zijn wie autorisaties goedkeurt, wie meldingen over integraties opvolgt en wie controleert of een patch werkelijk het complete aanvalspad afsluit.

Daarnaast moet er een duidelijk onderscheid worden gemaakt tussen ‘responsible disclosure’ en voorafgaande toestemming voor penetratietests. Het direct staken van tests en het melden van het lek getuigen van ethisch handelen na de ontdekking. De bug bounty toont aan dat de bevinding serieus is genomen. Geen van beide betekent echter automatisch dat er vooraf toestemming was voor alle uitgevoerde handelingen; de formele scope van een bugbountyprogramma blijft een afzonderlijk criterium.

Wie profiteerde en wie maakte kosten?

Voor de onderzoekers vertaalde het succes zich concreet in de uitbetaalde bounty zoals genoemd in de tabel. De reputatiewinst is reëel maar lastig te kwantificeren: een dergelijke publicatie toont technische expertise aan, maar biedt geen garanties voor toekomstige opdrachten. De geloofwaardigheid van zo’n publicatie hangt immers af van technische zorgvuldigheid en een evenwichtig verslag, niet van sensatiezucht.

Voor de getroffen platformbeheerders bestond het tastbare resultaat uit de bevestigde patch en de officiële verklaringen op de tijdlijn. De opgedane kennis is waardevol om vergelijkbare ketenafhankelijkheden binnen de organisatie tegen het licht te houden. Herstelwerkzaamheden, incidentbehandeling en architectuuranalyses brengen vanzelfsprekend kosten met zich mee, maar dit betreft operationele inspanningen en geen vastgestelde financiële schade. Het heeft dan ook weinig zin om die uren simpelweg af te zetten tegen het uitgekeerde bounty-bedrag.

Voor eindgebruikers en medewerkers stond de integriteit van accountgegevens op het spel. Een potentiële dreiging mag echter niet worden verward met feitelijke diefstal of misbruik van gegevens; daarvan was geen sprake. Voor leveranciers van AI-modellen genereert zo’n casus media-aandacht rondom de bruikbaarheid van hun tools, al vormt dit incident geen objectieve vergelijkende benchmark tussen verschillende AI-systemen.

Lessen voor organisaties en individuele gebruikers

Een gedegen security review leidt tot harde besluiten over rechten en autorisaties, niet louter tot een overzicht van actieve tools. Een organisatie heeft behoefte aan een heldere afhankelijkhedenkaart: een overzicht dat aantoont welke koppelingen essentieel zijn en waar toegangsrechten direct kunnen worden ingeperkt zonder de functionaliteit te schaden.

• Wijs voor elke integratie een vaste eigenaar aan die waakt over de vertrouwensgrenzen.
• Houd authenticatie (inloggen) strikt gescheiden van autorisatie (toegang tot specifieke data en acties).
• Leg duidelijke escalatie- en meldingspaden vast tussen verschillende softwareleveranciers en interne beheerders.
• Bepaal voorafgaand aan beveiligingsonderzoek duidelijke spelregels: de reikwijdte van tests, stopcriteria en kaders voor het gebruik van AI-tools.

Als individuele gebruiker heb je een andere rol. Je kunt controleren welke externe diensten aan je hoofdaccount zijn gekoppeld en overbodige rechten intrekken, maar fundamentele architectuurfouten bij een provider kun je via je accountinstellingen niet verhelpen. Transparante uitleg van een platform over ingebouwde controlemechanismen is dan ook veel waardevoller dan een algemene belofte dat SSO per definitie veilig is.

Hypothetisch voorbeeld: een bedrijfsforum en een werknemersaccount

Stel dat een organisatie een intern discussieforum wil inrichten en medewerkers via centrale SSO wil laten inloggen. Men wil voorkomen dat iedereen aparte inloggegevens moet aanmaken, maar het forum zelf heeft geen enkele toegang nodig tot gevoelige bedrijfssystemen of codeopslagplaatsen. Het dilemma is dan niet ‘gemak versus veiligheid’, maar ‘welk vertrouwensniveau is strikt noodzakelijk om dit gemak te realiseren?’.

• Het bedrijf scheidt de controle van identiteit (wie ben je) strikt van verdere toegangsrechten (wat mag je). Mocht een bredere koppeling noodzakelijk lijken, dan moet de eigenaar die expliciet motiveren in plaats van standaard alles open te zetten.
• Het team legt vast wie meldingen over integratieproblemen opvolgt. Het feit dat verschillende leveranciers betrokken zijn, mag er nooit toe leiden dat niemand zich verantwoordelijk voelt.
• De werknemer controleert de actieve app-koppelingen. Blijkt het onmogelijk om overbodige rechten zelf in te perken, dan stelt de gebruiker hierover vragen aan de beheerder in plaats van zelf op onderzoek uit te gaan.

Deze werkwijze betekent niet dat je Single Sign-On overboord moet gooien. Het vraagt simpelweg om bewuste keuzes: welke permissies zijn echt nodig en hoe koppel je overbodige privileges veilig los? Dit is een illustratie van de geleerde lessen, geen beschrijving van een specifiek incident.

Wat we nog niet weten

Het openbare rapport vermeldt niet exact hoe groot de bijdrage van het AI-model was, wat de totale onderzoekskosten waren of hoe groot de potentiële schade werkelijk had kunnen zijn. Er ontbreekt een directe vergelijking met een situatie waarin zonder AI gewerkt zou zijn, evenals details over eventuele verdere toegangsmogelijkheden. De kernconclusie blijft echter overeind: beoordeel een softwarekoppeling altijd op basis van de toegekende vertrouwensrechten, en nooit op basis van het imago of de schijnbare eenvoud van de dienst.

Aandachtspunten voor de beheerder van integraties

Een audit van SSO-koppelingen start idealiter met een vertrouwenskaart: welke externe diensten ontvangen bevestigingen van identiteiten en welke acties kunnen zij met die tokens uitvoeren? De beheerder van een extern forum en de beheerder van interne platforms zijn vaak verschillende partijen, maar voor de eindgebruiker lijken ze deel uit te maken van dezelfde organisatie. Een duidelijke taakverdeling zorgt ervoor dat er direct actie wordt ondernomen zodra een kwetsbaarheid wordt gemeld.

Bronnen

• Hacktron: Hacking OpenAI - 13-09-2026.
• CERT-EU: registratie van meldingen - oktober 2026; zonder specifieke dagvermelding.