The recipient clicked a link. That was the entire attack. No app to install, no file to open, no code to paste, no permission prompt to approve. What loaded was an ordinary public ChatGPT share, the kind the product has generated in volume since the feature arrived in 2023.
Inside that page, according to a technical write-up published by the security firm Parameter, a sequence of small and individually defensible design decisions added up to something else: JavaScript executing as chatgpt.com, inside the visitor’s signed-in session, able to enumerate their conversation history and read a chat that had never been shared with anyone.
Parameter said it reported the flaw to OpenAI through its bug bounty program on Oct. 18. OpenAI fixed it on Oct. 26 and classified the report as P1, the most serious category in its scale. The researchers said their tests ran between accounts they controlled and that they found no sign of the technique being used against real users.
The mechanism is worth following closely, because nothing in it was exotic. ChatGPT renders an HTML code block in its Preview feature inside a frame served from a different web address. That isolation works: code in the preview cannot read the parent page. The same conversation also held a chart, and the chart pulled in MathLive, a widely used library for typesetting mathematics, which installs a listener in the main ChatGPT page to handle messages from its on-screen keyboard.
Browsers provide that channel deliberately. A restricted frame cannot read its parent, but it can post a message to it, and the receiver is supposed to check who sent it. MathLive, for the setting Parameter exploited, did not. Its listener accepted a message from any origin, and the message it accepted replaced the keyboard layout with markup supplied by the sender.
When the keyboard opened, MathLive joined that markup into a string and assigned it to the page as HTML. A helper function named createHTML looked as though it would sanitize the input; it marked the string as trusted and passed it through untouched.
Inserted script tags do not run that way, which is where most attempts would have stopped. The chain continued with an iframe carrying its content in a srcdoc attribute and no sandbox flag. A frame created by the chatgpt.com page inherits that page’s origin, so code inside it could reach back out to the session around it.
ChatGPT’s Content Security Policy then blocked inline script, and would have ended the exercise. The policy did allow scripts from YouTube, and YouTube’s oEmbed endpoint echoed a callback parameter into its response before validating it. A crafted callback, terminated so the appended object did nothing, executed inside the new frame.
From there the payload acted as the visitor. It called the product’s own backend endpoints with the session’s bearer token, first to list recent conversations, then to retrieve one in full, then to transmit a fragment of it to an external server through an image request after clearing references to the token and account from memory. The researchers noted that the same access would have allowed changes to the account itself.
The commercial stakes sit in what a ChatGPT account now holds. A session carries months of work conversations, uploaded documents, connected applications and billing details. The product’s sharing feature was designed as a way to publish a conversation, and links were treated as content: static text that anyone could open. The flaw made the link a program.
OpenAI has spent three years tightening the perimeter around that surface, and the visible record shows a pattern of quick retreats. Shared links were crawlable by search engines until August 2023, when the company removed them from indexing after users discovered their chats in search results. Public-by-link, the model the industry settled on, still means anyone holding the URL can read the page.
What Parameter found is a distinct problem from prompt injection, the risk that a model follows instructions hidden in the material it reads. Here the attacker never needed the model to misbehave. The weakness sat in the plumbing around it: a charting library, an unauthenticated message listener, an HTML sink, a frame without a sandbox flag, and a third-party endpoint allowed by policy.
That combination is common in assistant products, which assemble math renderers, chart engines, map widgets, PDF viewers and embed players inside a single trusted origin. Each component is maintained by someone else, each is granted the trust of the page it lands in, and every one of them is a bridge across a boundary the product believes it has built.
The bug bounty route worked as intended, and eight days from report to fix is fast by the standards of enterprise software, where ninety-day disclosure windows remain the norm. The compensation was modest relative to the impact, a recurring complaint among researchers who argue that AI companies underprice flaws in session-handling code.
Parameter’s closing advice was aimed at builders rather than users: authenticate both the origin and the source of any message that changes state, keep untrusted markup sandboxed through its whole rendering path, and treat every public or shareable surface as attacker-controlled input.
For security teams at companies that have standardized on the tool, the practical lessons are narrower. A shared link arriving from outside the organization deserves the suspicion given to any attachment, previews that render code are worth disabling by default, and unusual calls to the product’s conversation endpoints from unexpected clients are worth alerting on.
None of that addresses the underlying condition. The assistant’s own page had to trust its components in order to work, and one of those components was willing to carry a stranger’s instructions into the room.
