A malicious ChatGPT share link could run an attacker’s code in the logged-in session of anyone who opened it, allowing them to read their private conversations, researchers at the security firm Parameter showed.
The researchers reported the flaw through OpenAI’s bug bounty program on October 18, and OpenAI fixed it eight days later and rated it P1, its most serious category.
The trap was an ordinary ChatGPT conversation shared via its public link. It could be sent the same way as any real shared chat: by email, as a chat message, as a support ticket, or as a social post.
The victim did not have to install anything, join a workspace, or sign in through the attacker. In the most reliable version of the attack, they opened the link and clicked ChatGPT’s Preview button once. In a later version, Parameter set the page to open Preview on its own, so opening the link was the only step.
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 copying what happened to be on the screen. Because it ran with the victim’s full web access, its reach was not limited to those chats. “Essentially, we could perform any action on behalf of the victim’s ChatGPT account,” the researchers wrote.
The work was a controlled test. Parameter does not report any real-world use of the flaw, and ran its private-chat proof between separate accounts rather than against real users.
How the Link Broke Out of Its Sandbox
Here is how the chain worked, according to Parameter. ChatGPT can turn a block of HTML in a chat into a small web page through a feature called Preview. Because that page can hold any code, ChatGPT runs it in a locked-down frame on a separate web address, where it cannot read the main ChatGPT page around it.
That sandbox held. The way in came from 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 messages about its on-screen keyboard.
A message passed between browser frames is safe only 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. The Preview could then reach across the boundary and hand attacker HTML to the trusted main page.
That HTML built a new frame that the browser treated as part of chatgpt.com. A script loaded from YouTube then supplied the code that ran inside it.
ChatGPT’s content security policy limits where a page’s scripts may come from. It blocked inline code but allowed scripts from YouTube, which is why that step worked.
What OpenAI Fixed, and What Users Should Do
Parameter said 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 researchers traced the problem to three design choices that lined up:
- MathLive acted on a message that changed its settings without checking which frame had sent it.
- That message was allowed to carry raw HTML as keyboard-layout data.
- The HTML could create a frame that was not sandboxed and inherited the chatgpt.com identity.
The YouTube step was only the final workaround, not the cause. Blocking it alone would still leave an untrusted Preview able to push HTML into the main site.
ChatGPT users do not need to do anything. The fix is on OpenAI’s side, with nothing to install or reset.
Parameter published its writeup on October 28, after the fix. OpenAI paid a total of $5,000 for the report.
