Shared ChatGPT link could run attacker code, read private chats

Key Points

1. Researchers showed a malicious ChatGPT share link could execute code inside a victim's signed-in session.
2. The planted code listed recent conversations and pulled text from a chat never shared with the attacker.
3. OpenAI rated the flaw P1, its most serious tier, and patched it within eight days.

The latest:

A single ChatGPT share link was enough to run an attacker’s code inside the session of anyone who opened it, with the same access as the real site, according to security firm Parameter. The firm said it reported the flaw to OpenAI on October 18. OpenAI raised the severity from P2 to P1 and shipped a fix eight days later.

Details:

• The attack path: Parameter said the trap was an ordinary ChatGPT conversation shared through its public link, deliverable by email, chat message, support ticket or social post. The victim did not need to install anything, join a workspace, or sign in through the attacker.
• User interaction: In the most reliable version, the researchers said the victim opened the link and clicked ChatGPT’s Preview button once. In a later version, Parameter made the page trigger Preview automatically, leaving opening the link as the only required step.
• What the code did: According to Parameter, the code listed the victim’s recent conversations, opened a private chat never shared with the attacker, and sent part of it to a researcher-controlled server. It called ChatGPT’s signed-in APIs directly rather than scraping the screen.
• Scope of access: Because the code ran with the victim’s full web access, the researchers said its reach was not limited to conversations. “Essentially, we could perform any action on behalf of the victim’s ChatGPT account,” they wrote.
• The sandbox: Parameter said ChatGPT renders HTML blocks as small web pages through Preview, isolated in a locked-down frame on a separate address. That sandbox held; the opening came from a second feature in the same conversation.
• The weak link: An interactive graph in the shared chat loaded a math library called MathLive into the main ChatGPT page, leaving a listener for on-screen keyboard messages. Parameter found the listener accepted messages from any sender and let them carry raw HTML.
• The escape: That HTML, handed to the trusted page, built a new frame the browser treated as part of chatgpt.com, the researchers said. ChatGPT’s content security policy blocked inline code but permitted scripts from YouTube, which supplied the executing code.
• Three root causes: Parameter traced the chain to a settings message acted on without checking the sending frame, that message being allowed to carry raw HTML, and the resulting frame inheriting the chatgpt.com identity unsandboxed. The YouTube step was a final workaround, not the cause.
• The fix: Parameter said OpenAI reproduced both the code execution and the private-chat proof and rolled a fix across two versions of the web frontend, with both rejecting the relevant messages by October 26. OpenAI paid $5,000 for the report.
• No known abuse: The work was a controlled test, and Parameter reports no real-world exploitation. The private-chat demonstration ran between separate researcher accounts. Users need take no action; the fix sits entirely on OpenAI’s side.

Between the lines:

The researchers’ own framing puts the weight on design, not on the YouTube script: blocking that path alone would still leave an untrusted Preview able to push HTML into the trusted page. The severity upgrade from P2 to P1 tracks the second proof — moving from running code to reading a conversation the attacker was never given.

What’s next

Parameter published its writeup on October 28, after the patch shipped. Watch for whether OpenAI tightens frame-message validation beyond the two frontend versions already fixed, and whether similar listeners appear in other embedded libraries.