A shared ChatGPT link is about the least suspicious thing on the internet. Someone forwards a conversation, you click it while signed in, and a stranger’s chat is in front of you. In October 2026, that click could have handed the sender a copy of your private conversations.
The research team at Parameter Labs turned an ordinary public share into attacker-controlled JavaScript running inside the signed-in session of whoever opened it. Mukul Goyal published the writeup on October 28. OpenAI reproduced the issue, raised severity from P2 to P1, fixed it across two web frontends and marked it resolved on October 26. The bounty totalled $5,000. The Hacker News notes that Parameter does not report any real-world use of the flaw.
How a graph and a preview walked out of a sandbox
ChatGPT can turn an HTML code block into a working small web page through its Preview feature. Because that page can hold arbitrary code, OpenAI runs it inside a restricted frame on a separate web address, where it cannot read the main ChatGPT page around it. Parameter’s report is explicit: “The Preview sandbox itself worked.”
The escape route came from a second feature in the same conversation: an ordinary interactive graph, which loaded a math library called MathLive into the main chatgpt.com page and installed a listener for messages about MathLive’s on-screen virtual keyboard. “That is safe only if the receiver checks who sent the message. MathLive did not make that check for the setting we were interested in,” the report says.
The Preview sent two of those messages: one replacing a keyboard layout with attacker-controlled HTML, one telling MathLive to show the keyboard. MathLive’s top-level controller “used an origin policy of none”, so it accepted messages from any web address. When the keyboard opened, MathLive joined the layout into an HTML string and assigned it to innerHTML on the real ChatGPT page. A helper called createHTML looked like it might sanitise that string. “It did not; it marked the string as trusted and passed our HTML through unchanged,” Parameter writes.
Script tags dropped in through innerHTML do not execute, so the researchers used an iframe with an srcdoc attribute, inserted without a sandbox attribute. That created a fresh document which inherited the chatgpt.com identity.
ChatGPT’s content security policy stopped them again. It blocked inline JavaScript but allowed scripts from YouTube, whose oEmbed endpoint supported a JSONP-style callback parameter. “The endpoint tried to reject an invalid callback, but it placed the callback into the response before returning its validation error,” Parameter writes. The browser loaded that response as an allowed script, and arbitrary JavaScript executed as chatgpt.com.
What the payload could reach
Delivery was a normal share URL, /share/<id>. In the most stable version, the victim opened the share and clicked ChatGPT’s Preview button once. The researchers later marked the HTML block as previewable so that opening the link was the only step.
Once running as chatgpt.com, the injected code parsed the page’s #client-bootstrap block, pulled out the session access token and account ID, and sent them as Authorization: Bearer and ChatGPT-Account-ID headers. It called the conversation API to list the victim’s recent chats, then to pull messages from one of them: a private conversation that had never been shared with the attacker. Data left the page through an ordinary image request to a server the researchers controlled. They sent only a small piece of it, and noted the code had already received the full authenticated response, so that limit was one they chose rather than one the bug imposed.
“The result was a practical cross-user data-theft primitive,” Parameter writes. Earlier in the report it goes further: “Essentially, we could perform any action on behalf of the victim’s ChatGPT account.”
Simon Willison, writing up the disclosure, put the risk in one line: “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.”
Why this class of bug keeps coming back
Parameter’s diagnosis is that three design decisions lined up: MathLive accepted a state-changing message without proving which frame sent it, the message format allowed raw HTML to travel as keyboard-layout data, and that HTML was able to create an unsandboxed document that inherited the chatgpt.com identity. Each piece looked reasonable alone. “The vulnerability appeared only when all of those features were combined in one page,” the report says, and its takeaway is blunt: “Cross-feature testing matters.”
The YouTube step was, in the researchers’ words, “the final workaround for CSP, not the root cause.” Their defensive list is short: authenticate both event.origin and event.source before acting on a cross-window message, keep raw HTML out of cross-window settings, keep dynamically created documents sandboxed, and treat CSP as a backup control rather than “the only barrier after attacker-controlled HTML reaches the main site.”
Willison’s version of the same point: “It’s important that HTML in these stays tightly sandboxed to avoid untrusted code interacting with OpenAI APIs and accessing private data.” On the payout, he called a $5,000 bounty “a bit cheap for a vulnerability this serious.”
The pattern is not confined to one bug. On September 8, Check Point Research reported a separate cross-account channel inside ChatGPT, built on an internal JFrog Artifactory instance that the code-execution containers of separate accounts could all reach, which turned the package service’s metadata into “a shared clipboard between isolated containers”. In their proof of concept, ChatGPT retrieved email data from a victim’s connected Gmail account and relayed it to the attacker. Check Point says the channel was no longer available by the time it completed its report, and that OpenAI confirmed the internal Artifactory instance had been decommissioned.
What this means
The unit of risk here was the session rather than the page. The attack did not need to beat a login, steal a password or phish for a token; it needed code running inside chatgpt.com, and from there the authenticated APIs were available. Once code runs with a user’s session, its reach is whatever that user can reach, which is why the proof of concept reads a chat nobody shared rather than doing something visible on the page.
Delivery was ordinary too: no install, no workspace, no sign-in flow, just a link. What remains after the fix is a class of bug rather than a hole: a preview frame, a third-party math library pulled in by a graph, a document created from injected markup, and an allowlisted media host.
The Bottom Line
OpenAI rated the ChatGPT share-link escape P1, resolved it on October 26, 2026, and paid a $5,000 bounty. The fix is server-side, Parameter reports no real-world exploitation, and users did not need to do anything.
The part worth remembering is the shape of the bug rather than the date it was patched. A sandboxed preview that could not read the page it sat in, and a listener on that page willing to take instructions from anyone. “The Preview sandbox itself worked”, the report says. The product around it did not.
Related on Intelligibberish
- Claude Cowork’s SharedRoot escape: a one-prompt path to your Mac - an earlier case of the same shape
- Privacy