ChatGPT Share-Link Flaw Let One Link Read Private Chats

A malicious ChatGPT share link could run attacker-controlled JavaScript inside the signed-in session of a person who opened it, letting the researchers behind the test list recent conversations and read a private chat that had never been shared.

Security firm Parameter reported the flaw to OpenAI on October 18 and published its technical account after the company fixed it. According to the disclosure, OpenAI reproduced the code execution and private-chat proof, upgraded the report from P2 to P1, and completed a server-side fix across two versions of the ChatGPT web frontend on October 26.

The research does not describe a continuing vulnerability or known attacks against real users. Parameter says its data-theft demonstration ran between controlled accounts, and The Hacker News reported that no real-world exploitation was identified. Users do not need to install an update or reset a password because of this specific flaw.

How a shared ChatGPT link crossed the sandbox

The exploit did not simply “break” ChatGPT’s HTML Preview sandbox. That restricted frame remained on a separate web origin and could not directly read the surrounding chatgpt.com page. The route out appeared only when several otherwise separate features were combined in one public conversation.

1. An interactive graph loaded MathLive. ChatGPT used the open-source math-input library in the main, authenticated page. MathLive installed a browser message listener for its virtual keyboard.
2. A sandboxed HTML Preview sent two cross-frame messages. One message supplied a replacement keyboard layout containing attacker-controlled markup. The other instructed MathLive to display that layout.
3. The listener trusted the wrong sender. Parameter found that the relevant MathLive controller accepted the setting change without checking the sending frame’s origin or confirming that the message came from an approved window.
4. Raw markup reached the main page. The virtual keyboard path assigned the supplied layout to innerHTML. A helper called createHTML acted as an identity or Trusted Types wrapper, not a sanitizer.
5. An unsandboxed srcdoc frame inherited the ChatGPT origin. A script tag inserted through innerHTML would not run on its own, but the injected frame created a new document that the browser treated as part of chatgpt.com.
6. A YouTube endpoint supplied executable code. ChatGPT’s Content Security Policy blocked inline scripts but allowed YouTube as a script source. Parameter used a JSONP-style callback on YouTube’s oEmbed endpoint to execute JavaScript in the new same-origin frame.

The graph and Preview were both preserved when the attacker published the conversation through ChatGPT’s normal sharing feature. In the researchers’ most reliable version, the recipient opened the link and clicked Preview once. They later made Preview open automatically; in that version, navigating to the share link was the only user action, and the payload appeared after about 4.5 seconds in repeated tests.

What the proof could access

Once the injected code ran as chatgpt.com, it read session information already available to the web application and called ChatGPT’s authenticated conversation endpoints. Parameter’s proof enumerated the victim account’s recent conversations, requested content from an unrelated private chat, and sent a small selected value to a researcher-controlled server through an image request.

That is materially different from scraping whatever text happened to be visible in the shared page. The code made signed-in API requests as the victim. Parameter concluded that the JavaScript context could reach other data and actions exposed through the web frontend, although the published proof deliberately limited its exfiltration and did not demonstrate every possible account action.

A Cloud Security Alliance analysis notes that the same architectural pattern matters beyond ChatGPT: AI interfaces increasingly render charts, math, diagrams, code and live previews beside an authenticated session. Every library that adds a cross-frame listener or writes rich content into the page becomes part of that security boundary.

What OpenAI fixed

Parameter says OpenAI rolled the remediation through two web frontends. During the rollout, Content Security Policy changes blocked one part of the original exploit while a second frontend still needed an update. By October 26, both versions rejected the cross-frame MathLive messages used in the report, and OpenAI marked the issue resolved. The company paid a total bug bounty of $5,000.

The YouTube callback was the last execution step, not the root cause. Removing that one endpoint would have broken the published chain, but it would still have left a sandboxed, untrusted frame able to push raw HTML into the authenticated parent page. The durable fix had to close the message path.

What ChatGPT users should do

No special cleanup is required for the patched vulnerability. There is no client update to install, and the disclosure does not establish that passwords or accounts were stolen in the wild.

The delivery method still changes how shared AI links should be treated. A chatgpt.com/share/... address can carry content created by another user, even though the domain belongs to OpenAI. Unsolicited shared chats deserve the same caution as unexpected document-sharing links: confirm who sent them, avoid opening them from sensitive administrative sessions when the source is unclear, and report suspicious links through normal security channels.

Users can also review links they have published. OpenAI’s shared-conversation guidance explains how to manage and delete shared links, and warns that anyone permitted to open a personal-account link can view the material included in it. Deleting old shares is sensible privacy hygiene, but it is not a required remediation for Parameter’s now-fixed exploit.

A practical audit for web and AI product teams

Applications that embed previews or third-party renderers should inventory every message event handler in their own code and dependencies. Search for addEventListener("message", ...) and onmessage, then verify each handler against five questions:

• Does it compare event.origin with a narrow allowlist rather than accepting any origin?
• Does it verify event.source against the exact frame or window expected to send the message?
• Is the payload validated against a strict schema before any state change?
• Can any message-controlled value reach innerHTML, a Trusted Types identity policy, srcdoc, or another HTML-producing sink?
• Can a dynamically created frame inherit the authenticated parent origin or omit an appropriate sandbox attribute?

MDN’s postMessage documentation recommends checking both origin and message syntax, while the OWASP HTML5 Security Cheat Sheet advises treating received data as data rather than evaluating it or inserting it as HTML.

Content Security Policy remains useful defense in depth, but this case shows why a host-based script allowlist is not a sanitizer. Teams should prune third-party script origins, prefer nonce- or hash-based policies where feasible, and test whether allowed services expose JSONP callbacks or other reflected script behavior. Session tokens should also stay out of DOM-accessible bootstrap data when possible, although HttpOnly cookies alone cannot stop same-origin injected code from making requests inside an already active session.

The practical lesson is narrower than “sandboxes do not work.” ChatGPT’s Preview isolation worked until trusted code outside the sandbox accepted an unauthenticated instruction and created a new privileged document. Security reviews have to follow every bridge across the boundary, including the ones installed by components that seem unrelated to the feature being tested.