ChatGPT share links could run attacker code and read private chats

Researchers at Parameter showed that a normal ChatGPT share link — the public "share this conversation" feature — could run attacker-controlled JavaScript inside a victim's signed-in session and read conversations the attacker was never shared on. OpenAI fixed it on October 26. There is nothing for users to install, but the chain is a clean lesson for anyone building an LLM web front end.

What the attack did

In Parameter's proof of concept, the victim only had to open the shared link. In the most reliable version the page auto-executed after roughly 4.5 seconds. Once running, the code had the victim's full authenticated access: it listed recent conversations, opened a private chat that had never been shared, and sent its contents to a researcher-controlled server. The writeup, titled "Do the Math: How We Took Over ChatGPT Accounts" and authored by Mukul Goyal, puts it plainly — the code could act on behalf of the victim's account.

The chain

The interesting part is how a static shared conversation turned into code execution under the chatgpt.com origin:

1. The shared chat contained an interactive graph that loaded the MathLive math library into the main ChatGPT page.
2. MathLive installed a cross-frame message listener that did not verify the sender's origin.
3. A sandboxed HTML Preview in the same conversation sent messages to that listener carrying raw HTML.
4. That HTML created an unsandboxed frame that inherited the chatgpt.com identity.
5. Script in that frame ran under the real origin. ChatGPT's Content Security Policy blocked inline scripts but allowed a third-party endpoint (YouTube), which is the gap the payload loaded through.

No single bug here is exotic. The compromise is the composition: an origin-blind postMessage handler, raw HTML crossing a frame boundary, and a CSP allowlist entry that could be turned into a script source.

Disclosure timeline

Parameter reported the issue through OpenAI's Bugcrowd program on October 18. OpenAI reproduced it on October 21 and raised the severity from P2 to P1. Fixes rolled out across two versions of the web front end; by October 26 both rejected the cross-frame MathLive messages the attack relied on, and OpenAI marked it resolved. Total bounty: $5,000. The researchers report no real-world abuse — this was a controlled test. No CVE was assigned.

What to do

For ChatGPT users: nothing. The fix is server-side, there is nothing to install or reset, and opening old share links is now safe.

For engineers shipping LLM or document-rendering web UIs, the takeaways are concrete:

1. Verify the origin of every postMessage. An event listener that acts on any sender is an open door between frames.
2. Never pass raw HTML across a frame boundary and act on it. Treat cross-frame payloads as untrusted data, not markup.
3. Keep dynamically rendered documents sandboxed. A frame that can shed its sandbox and inherit your origin is a full compromise.
4. Treat CSP as defense-in-depth, not the fix. A single trusted third-party script endpoint in the allowlist was enough here; blocking YouTube alone would not have closed the hole.

Context

This is the same seam we keep seeing on the AI beat: the model isn't the vulnerability, the web plumbing around it is. It sits next to earlier ChatGPT-surface abuse like the ClickFix custom-GPT RAT lure — different mechanism, same lesson that an assistant's rich rendering surface is now part of its attack surface. The responsible-disclosure handling here, from a P2-to-P1 bump to a fix in eight days, is the part other outlets undersold.