Direct naar de inhoud
Cybersecurity

Aangevallen via gedeelde ChatGPT-link: code in sessie

gedeelde ChatGPT-link

Een gedeelde ChatGPT-link bleek in een kwetsbare situatie niet alleen een gewone preview van een gesprek te tonen, maar ook aanvaller-code te kunnen laten uitvoeren binnen de ingelogde sessie van de ontvanger. Daardoor konden onderzoekers privégesprekken inzien en zelfs acties uitvoeren namens de gebruiker.

Het goede nieuws: OpenAI heeft de fout inmiddels verholpen en gebruikers hoefden niets zelf te installeren of opnieuw in te stellen. Toch is dit incident een duidelijke reminder dat “delen” bij webapps niet automatisch veilig is.

Wat was er aan de hand met de gedeelde ChatGPT-link?

Parameter beschreef hoe een kwaadwillende partij een ChatGPT-conversatie publiceerde via een gewone, publiek toegankelijke deel-link. De aanval bestond uit iets wat voor een gebruiker op een legale gedeelde chat leek—bijvoorbeeld via e-mail, een chatbericht, een supportticket of een post op social media.

De belangrijkste factor was dat de ontvanger geen extra handelingen hoefde te verrichten zoals installeren van software, lid worden van een workspace of opnieuw inloggen via de aanvaller. In de meest betrouwbare variant volstond het openen van de link en één keer klikken op de knop Preview in ChatGPT.

In een latere variant kon de preview zelfs automatisch openen, waardoor enkel het openen van de link genoeg was om de keten te starten.

Waarom kon de aanval privéchats uitlezen?

Zodra de link werkte, draaide er code binnen dezelfde webcontext als de echte ChatGPT-omgeving van het slachtoffer. Met andere woorden: de aanvaller kreeg toegang in het kader van de sessie die al was ingelogd.

Volgens de onderzoekers kon de code de recente gesprekken van het slachtoffer opsommen, daarna een private chat openen die niet met de aanvaller was gedeeld en vervolgens een klein deel daarvan doorsturen naar een server die de onderzoekers beheerden.

Cruciaal is dat de code niet “meekijkte” op basis van wat toevallig op het scherm zichtbaar was. In plaats daarvan riep de code de eigen ingelogde services en API’s van ChatGPT aan. Dat betekende dat de mogelijkheden in principe verder konden reiken dan alleen die specifieke chats.

Parameter vatte dit samen als: het uitvoeren van acties namens het ChatGPT-account. Daarbij ging het om een gecontroleerde test, niet om een bewijs van grootschalig misbruik in de praktijk.

Hoe brak de aanval uit de beveiligde sandbox?

ChatGPT heeft een preview-functionaliteit waarbij HTML uit een chat wordt omgezet naar een klein webpaginaatje. Die preview draait in een afgeschermd frame, zodat het niet eenvoudig kan lezen wat er rondom die preview op het hoofdplatform staat.

De verdediging hield stand zolang alles “binnen de lijntjes” bleef. De aanval kwam echter via een tweede component uit dezelfde conversatie.

In de gedeelde chat stond een interactief grafiekonderdeel dat een bibliotheek genaamd MathLive laadde. Het laden van die bibliotheek liet een listener draaien op de hoofdpagina die berichten kon ontvangen over de on-screen keyboard.

Het probleem zat in de manier waarop die listener controleerde waar berichten vandaan kwamen en welke inhoud mocht worden meegestuurd. Parameter stelde vast dat de listener berichten accepteerde vanuit elke afzender en dat die berichten ook ongefilterde HTML konden bevatten.

Vanaf dat punt kon de preview de grens oversteken en HTML aan de vertrouwde omgeving doorgeven. Vervolgens werd er een nieuw frame opgebouwd dat door de browser als onderdeel van chatgpt.com werd gezien.

De laatste stap om de code daadwerkelijk te laden draaide op scripts die wel binnen het toegestane script-bronbeleid vielen. De onderzoekers noemden daarbij dat een script vanaf YouTube als route werkte, omdat die bron was toegestaan volgens het content security beleid.

Belangrijk: YouTube was volgens Parameter een omzeilingsroute en niet de kernoorzaak. Het echte probleem zat in de combinatie van: berichtafhandeling, het toelaten van ruwe HTML en het kunnen creëren van een niet-afgeschermd frame met de identiteit van de hoofdpagina.

Wat deed OpenAI en wat betekent dat voor gebruikers?

Parameter meldde de bevindingen op 18 oktober via het bug bounty-programma van OpenAI. OpenAI repliceerde de aanval en de onderzoekers maakten een private-chat bewijsvoering. Vervolgens werd de ernst van de kwestie verhoogd van P2 naar P1, de hoogste categorie.

OpenAI rolde daarna fixes uit in twee versies van de ChatGPT-webfrontend. Binnen acht dagen—dus uiterlijk begin eind oktober—werden de specifieke berustende berichten waarop de aanval draaide afgewezen.

De onderzoekers publiceerden hun gedetailleerde write-up op 28 oktober, nadat de oplossing er al stond. Voor de melding keerde OpenAI in totaal $5.000 uit.

Voor gebruikers geldt: er hoefde niets aangepast te worden. De oplossing kwam van OpenAI zelf, zonder dat iemand iets hoefde te installeren, resetten of opnieuw in te loggen.

Hoe herken je dit soort risico bij “delen”?

Hoewel dit incident specifiek om ChatGPT-deellinks ging, is de onderliggende les breder toepasbaar op moderne webapplicaties: “delen” kan meer worden dan alleen content tonen. Het kan interactie, embedded weergave en dynamische elementen omvatten die—als er fouten zitten in validatie—kunnen leiden tot code-uitvoering of datalekken.

Praktische aandachtspunten voor organisaties en gebruikers:

  • Behandel gedeelde links van onbekende of onverwachte bronnen met dezelfde voorzichtigheid als links van e-mail phishings.
  • Beperk waar mogelijk de impact van accounttoegang: gebruik sterke authenticatie en voorkom dat één sessie te veel bevoegdheden heeft.
  • Let bij beveiligingsbeleid op webapplicaties met preview- of embedfuncties; dit soort features is vaak waar “grenzen” worden getest.
  • Volg advisering van de leverancier: in dit geval lag de fix bij OpenAI, niet bij gebruikers.

Vergelijkbare risico’s: wanneer content en uitvoering botsen

Dergelijke kwesties passen in een bredere trend waarin contentweergave (zoals previews, embedded grafieken en gelinkte UI-elementen) onverwacht kan interfereren met beveiligingsmechanismen. Als je wilt doorgronden hoe aanvallen soms via webcomponenten of integraties escaleren, kan dit artikel over beveiligde remediatie helpen om het denken rond detectie en herstel scherper te maken: Bron: https://thehackernews.com/2026/10/a-shared-chatgpt-link-could-run.html