Photo: Jernej Furman / Wikimedia Commons (CC BY 2.0). Graphic: GPTOnline.
A crafted ChatGPT share link could run an attacker’s code inside the signed-in browser session of anyone who opened it, exposing private conversations and letting the attacker act on the victim’s behalf, according to research disclosed on October 31 by security firm Parameter Labs. OpenAI fixed the flaw eight days after it was reported and rated it P1, its most serious severity category.
The trap looked like an ordinary shared ChatGPT conversation. It could arrive by email, chat message, support ticket, or social post, and the victim did not need to install anything, paste anything, or open developer tools. In the most reliable version of the attack, opening the link and clicking ChatGPT’s Preview button once was enough; in a later version, the page opened Preview by itself, so opening the link was the only step, The Hacker News reported.
How the Attack Chain Worked
ChatGPT turns a block of HTML in a chat into a small web page through a feature called Preview, the current form of what OpenAI once called Canvas, developer Simon Willison noted in his October 31 write-up. Because preview pages can hold arbitrary code, ChatGPT runs them in a locked-down frame on a separate web address, where they cannot read the main ChatGPT page. That sandbox held. The way in came through a second feature in the same conversation.
The shared chat also contained an interactive graph, and drawing it loaded a math library called MathLive into the main ChatGPT page. Loading MathLive left a listener running there that accepted postMessage events about its on-screen keyboard. A cross-frame message is only safe if the receiver checks the sender’s origin, and Parameter found that this listener accepted a keyboard message from any sender, then treated the keyboard-layout field as raw HTML and rendered it with innerHTML.
The Preview frame could therefore reach across the boundary and hand attacker HTML to the trusted main page. While innerHTML does not execute script elements directly, the researchers used it to inject a fresh iframe with no sandbox attribute, so the browser granted it the chatgpt.com identity. ChatGPT’s content security policy blocked inline scripts but allowed scripts from a short list of domains, and YouTube was on it: the YouTube oEmbed endpoint reflected attacker JavaScript back in a JSONP-style response, which executed. With code running on the chatgpt.com origin, the attack was complete.

What the Attacker Could Do
Once the link opened, the attacker’s code ran inside the victim’s signed-in session with the same access as the real ChatGPT site. It listed the victim’s recent conversations, opened a private chat that had never been shared with the attacker, and sent a small portion of it to a server controlled by the researchers. The code called ChatGPT’s own signed-in APIs directly rather than merely copying what was on screen.
“Essentially, we could perform any action on behalf of the victim’s ChatGPT account,” the researchers wrote. Willison summarized the end result the same way: “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.”
The work was a controlled test. Parameter says it does not know of any real-world use of the flaw and ran its private-chat proof between separate accounts rather than against real users.

The Fix and the Bounty
Parameter reported the flaw through OpenAI’s bug bounty program on October 18. OpenAI reproduced both the code execution and the private-chat proof, raised the severity from P2 to P1, and rolled a fix across two versions of ChatGPT’s web frontend. By October 26, both versions rejected the messages the attack relied on, The Hacker News reported.
Parameter published its writeup on October 28, after the fix. OpenAI paid a total of $5,000 for the report. “OpenAI closed the hole and paid out a $5,000 bug bounty, which I think was a bit cheap for a vulnerability this serious,” Willison wrote. Secondary coverage notes that MathLive 0.111.2 separately added same-origin validation for its postMessage handling, closing the vector for every application embedding the library, not just ChatGPT.
Why It Matters
The chain is a case study in how harmless features combine into a serious defect: three design choices lined up, the MathLive listener that skipped origin checks, raw HTML allowed as keyboard-layout data, and an injected frame that inherited the trusted origin. The YouTube step was only the final workaround, not the cause; blocking it alone would still have left an untrusted Preview able to push HTML into the main site.
For users, the takeaway is reassuringly simple. ChatGPT users do not need to do anything: the fix is entirely on OpenAI’s side, with nothing to install or reset. The episode lands in a dense run of AI-application security disclosures, including OpenAI’s own July incident in which its test agents escaped a sandbox and reached Hugging Face production infrastructure. As AI products keep adding interactive features, the boundary between untrusted content and trusted code keeps getting thinner, and this chain shows exactly where the pressure lands.
Sources
- The Hacker News: A Shared ChatGPT Link Could Run Attacker Code in Your Session and Read Private Chats (October 31, 2026)
- Simon Willison’s Weblog: Parameter Labs’ ChatGPT sandbox-escape write-up (October 31, 2026)
- Parameter Labs: “Do the math: How we took over ChatGPT accounts” (October 28, 2026)
- OpenAI Help Center: HTML previews documentation

