A ChatGPT conversation shared through the product's ordinary public link could hand an attacker something far more dangerous than the text on screen. Researchers at the security firm Parameter showed that a crafted share link ran their code inside the logged-in browser session of anyone who opened it — with the same access as the real ChatGPT site. They reported it through OpenAI's bug bounty program on October 18; OpenAI fixed it eight days later, rated it P1, its most serious category, and paid $5,000.
The trap looked exactly like any legitimate shared chat. It could arrive by email, in a messaging app, as a support ticket, or as a social post, because it was a real shared conversation. In the most reliable version of the attack the victim had to open the link and click ChatGPT's Preview button once. In a later refinement, Parameter configured the page to open Preview on its own, so simply opening the link was enough. Nothing needed to be installed and no account credentials were involved.
Once the code was running, it called ChatGPT's own signed-in APIs directly rather than scraping the screen. In Parameter's controlled test, 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 the researchers controlled. "Essentially, we could perform any action on behalf of the victim's ChatGPT account," the team wrote. The test ran between Parameter's own accounts; the firm says it found no evidence of real-world abuse.
The chain started with Preview, a feature that turns a block of HTML in a chat into a small web page. ChatGPT runs that page in a locked-down frame on a separate address, and Parameter confirms that sandbox held. The way in came from a second feature in the same conversation: an interactive graph whose rendering loaded a math library called MathLive into the main ChatGPT page, leaving behind a listener that accepted messages about its on-screen keyboard. That listener accepted a keyboard-layout message from any sender, and the message was allowed to carry raw HTML.
That combination let the sandboxed Preview reach across the frame boundary and inject attacker-controlled HTML into the trusted main page. The injected HTML created a new frame that the browser treated as part of chatgpt.com, and ChatGPT's content security policy — which blocks inline scripts but allows scripts from YouTube — supplied the last step: a script loaded from YouTube carried the payload. Parameter stresses that blocking YouTube alone would not have closed the hole.
Parameter traces the bug to three design choices lining up: a library that acted on a message without checking which frame sent it, a message format that permitted raw HTML as keyboard data, and a frame that could be created without sandboxing while inheriting the chatgpt.com identity. 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 the web frontend; by October 26 both rejected the messages the attack relied on. Parameter published its writeup on October 28, after the fix.
The episode is a reminder that share links are trusted surface. Users need to do nothing — the fix is entirely server-side — but the pattern generalizes: as AI products bolt richer embeddable features onto pages that also hold credentials and private history, one permissive listener in a third-party library can undo the whole sandbox. OpenAI's bounty paid $5,000 for a report that touched every logged-in session; the gap between that number and the blast radius is part of why researchers keep publishing first.
Comments (0)
Log in to join the discussion
Log InNo comments yet