Skip to content
NewsIncident

OpenAI fixed a ChatGPT share link flaw that ran attacker code in a victim's signed-in session

· by

The short version

Security firm Parameter showed that an ordinary shared ChatGPT conversation could execute attacker JavaScript inside a victim's logged-in account, reading private chats without any click beyond opening the link.

OpenAI fixed a ChatGPT share link flaw that ran attacker code in a victim's signed-in session

A ChatGPT conversation shared through the normal public-link feature could be turned into a vehicle for attacker JavaScript that ran inside the victim's own logged-in session, according to security firm Parameter. Opening the link, and in the most reliable version of the attack doing nothing else at all, was enough.

What happened

Parameter reported the flaw through OpenAI's bug bounty program on October 18, and OpenAI shipped a fix eight days later, on October 26, per Parameter's writeup. OpenAI reproduced the attack, raised its internal severity rating from P2 to P1 (its most serious bug bounty category), and paid a total of $5,000 across the two reports. Parameter published the technical details on October 28, after the patch was live, and The Hacker News covered the disclosure on October 31.

The trap was an ordinary shared chat containing two features that are each safe on their own: an interactive graph and an HTML Preview block. Drawing the graph loaded a math-rendering library, MathLive, into the main chatgpt.com page to support its on-screen keyboard. That library listened for configuration messages sent through the browser's postMessage API but never checked which frame had sent them, and it accepted raw HTML as part of that message. ChatGPT's Preview feature runs in a sandboxed frame specifically so it cannot read the page around it, and that isolation held. But the sandboxed Preview could still send a MathLive-formatted message across the frame boundary, smuggling attacker HTML into the trusted, unsandboxed main page. That HTML built a new frame the browser treated as part of chatgpt.com itself, and a script tag pointing at YouTube, a domain ChatGPT's content security policy already allowed, supplied the code that ran there.

Once running, the code called ChatGPT's own authenticated APIs directly rather than scraping the screen. It listed the victim's recent conversations, opened a private chat the attacker had never seen, and sent a portion of it to a server Parameter controlled. "Essentially, we could perform any action on behalf of the victim's ChatGPT account," the researchers wrote. Parameter said the proof-of-concept ran between its own test accounts and reported no evidence the flaw was exploited against real users.

Three individually reasonable design choices lined up into one exploit

None of the three pieces was broken in isolation. The Preview sandbox did what it was supposed to do. MathLive's keyboard feature works fine for users who never see a malicious share. The CSP's YouTube allowance exists for legitimate embeds. The failure was that nothing in the chain validated the origin of a cross-frame message before trusting its contents as same-page HTML. For any product that renders third-party content inside sandboxed frames next to a signed-in session, the lesson is narrow but concrete: a postMessage listener added by one feature can become an entry point for a completely unrelated feature's sandbox, and CSP allowlists built for one script don't limit what an attacker loads once that script's own listener is misused.

What to watch next

OpenAI's fix rejected the cross-frame messages the attack relied on across two versions of ChatGPT's web frontend; no user action is required. Watch for whether OpenAI tightens the CSP's third-party script allowances further, and for whether Parameter or other researchers find the same postMessage-origin gap in other AI products that mix sandboxed previews with shared, publicly linkable content.

Sources