A ChatGPT link read your chats

A malicious ChatGPT share link could run an attacker’s code inside the logged-in session of whoever opened it, read their private conversations, and call ChatGPT’s APIs as them. Researchers at the security firm Parameter reported the flaw through OpenAI’s bug bounty program on October 18. OpenAI fixed it eight days later and rated it P1, its most serious category, paying a total of $5,000 for the report.

The delivery was an ordinary shared chat. ChatGPT lets you publish a conversation at a public link, and the trap traveled the same way any real share does: by email, as a chat message, in a support ticket, as a social post. The victim installed nothing, joined no workspace, and never signed in through the attacker. In the most reliable version they opened the link and clicked ChatGPT’s Preview button once. Parameter later set the page to open Preview on its own, which left opening the link as the only step.

Once the link opened, the attacker’s code ran inside the victim’s signed-in session with the same access as the real site. It listed the victim’s recent conversations, opened a private chat that had never been shared with the attacker, and sent a portion of it to a server Parameter controlled. The code called ChatGPT’s own signed-in APIs directly rather than scraping whatever was on screen, so its reach was not limited to the chats on display. “Essentially, we could perform any action on behalf of the victim’s ChatGPT account,” the researchers wrote. This was a controlled test between separate accounts, and Parameter reports no real-world use.

How the preview escaped its sandbox

ChatGPT’s Preview feature turns a block of HTML in a chat into a small web page. Because that page can contain arbitrary code, ChatGPT runs it in a locked-down frame on a separate origin, where it cannot read the main ChatGPT page around it. That sandbox held on its own.

The way in came from a second feature in the same conversation. The shared chat also contained an interactive graph, and rendering it loaded a math library called MathLive into the main ChatGPT page. MathLive left a listener running there to accept messages about its on-screen keyboard.

A message passed between browser frames is only safe if the receiver checks who sent it. Parameter found that this listener accepted a keyboard message from any sender, and that the message was allowed to carry raw HTML as keyboard-layout data. That gave the sandboxed Preview a way to hand attacker HTML to the trusted main page. The HTML then built a new frame that the browser treated as part of chatgpt.com, inheriting the site’s identity instead of staying sandboxed.

The last piece was getting code into that frame. ChatGPT’s content security policy blocked inline scripts but allowed scripts loaded from YouTube, so a script hosted there supplied the payload. Parameter is explicit that the YouTube allowance was the final workaround and not the cause: blocking it would still leave an untrusted Preview able to push HTML into the main site.

What OpenAI changed

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.

Parameter traced the problem to three design choices that lined up: MathLive acted on a message that changed its settings without checking which frame sent it; that message could carry raw HTML; and the HTML could create a frame that was not sandboxed and inherited the chatgpt.com origin. Any one of these alone is survivable. Together they turn a public share link into code execution in a logged-in session.

The pattern generalizes past ChatGPT to anything that renders untrusted content next to trusted content. An origin-isolated sandbox is only as strong as the postMessage handlers listening on the parent origin, and one handler that skips the sender-origin check reconnects the two sides you spent effort separating. A CSP that allowlists a large third party has the same weakness: it narrows where scripts load from without making those scripts trustworthy.

ChatGPT users need to do nothing, since the fix is entirely on OpenAI’s side. Parameter published its writeup on October 28, after the fix shipped.