How We Took Over ChatGPT Accounts It's important that HTML in these stays tightly sandboxed to avoid untrusted code interacting with OpenAI APIs and accessing private data.
Parameter found quite a complex attack chain. OpenAI use the MathLive JavaScript library as part of their graph support, and that library includes its own virtual keyboard, which can be triggered in the parent page via postMessage() from the sandboxed iframe.
That message receiving code uses innerHTML, so anything that sends a message can add custom HTML to the parent - and there was no mechanism to prevent other sandboxed frames, including HTML preview frames, from calling that method.
This meant untrusted code in an iframe could insert HTML, and while innerHTML doesn't directly execute script elements it could be used to inject a new iframe without sandbox restrictions.
OpenAI’s CSP rules blocked inline scripts entirely, and only allowed script from a handful of domains, but one of those was YouTube - and the YouTube oEmbed endpoint could be used to reflect JavaScript back in a way that executed it.
Once the attack had JavaScript execution on ChatGPT, it was trivial to fetch private user data from APIs and exfiltrate it via an image reference.
The end result: you could create a ChatGPT share URL which, when visited by another signed-in user, could exfiltrate their private data or take actions on their behalf.
OpenAI closed the hole and paid out a $5,000 bug bounty, which I think was a bit cheap for a vulnerability this serious.
Via [Hacker News](https://news.ycombinator.com/item?id=50314699)
Tags: [iframes](https://simonwillison.net/tags/iframes), [javascript](https://simonwillison.net/tags/javascript), [sandboxing](https://simonwillison.net/tags/sandboxing), [security](https://simonwillison.net/tags/security), [xss](https://simonwillison.net/tags/xss), [openai](https://simonwillison.net/tags/openai), [chatgpt](https://simonwillison.net/tags/chatgpt), [content-security-policy](https://simonwillison.net/tags/content-security-policy)