Parameter disclosed on October 28, 2026, that a malicious ChatGPT shared conversation could run code inside another user's signed-in session and read private chats. The researchers say OpenAI fixed the issue on October 26. Their technical report describes a browser-security failure connecting graphs and HTML Preview, with a consequence beyond the conversation someone chose to open: access to conversations they had never shared.
The fix date and OpenAI's reported P1 classification come from Parameter's account. MrKeyoor has not independently reproduced the exploit or verified the remediation. The report documents a controlled private-data disclosure; it does not establish whether attackers exploited the flaw outside the research.
How Preview reached the signed-in page
ChatGPT's HTML Preview ran code in a restricted frame on a separate web address, according to Parameter's walkthrough. That frame could not directly read the surrounding ChatGPT page. A graph in the same conversation, however, loaded MathLive, a mathematics library whose virtual keyboard listened for messages in the main page.
Parameter says that listener accepted keyboard-layout changes without requiring an approved sending window, and its origin policy allowed messages from any web address. Layout data could contain HTML. A Preview could therefore send instructions that caused a trusted component to insert attacker-controlled markup into the signed-in page.
The researchers then used an unsandboxed embedded document and a YouTube endpoint allowed by ChatGPT's Content Security Policy to obtain JavaScript execution. In their account, the policy blocked inline scripts, but the allowed endpoint supplied a route around that restriction. The important failure for developers is the earlier handoff: untrusted frame messages had already acquired the power to change HTML in the parent page.
What the researchers demonstrated
Parameter says its payload listed recent conversations, retrieved content from a private conversation unrelated to the malicious share, and sent a small selected value to a server it controlled. Those were authenticated API requests, rather than a scrape of text already visible on screen. The report's account-takeover claim rests on code having the web application's authenticated access. The concrete disclosure proof described is narrower: a private-conversation read and an outbound request.
The delivery details also matter. The most stable reproduction required opening the shared conversation and clicking Preview. Parameter says it later made Preview open automatically, leaving the link visit as the only click. It reports reproducing that automatic path three times in a separate account, including after a hard refresh. The report describes retries to handle the graph and Preview loading at different times; it doesn't supply a success rate across a broad set of users or browsers.
Check the receiver as well as the sandbox
For anyone embedding untrusted content, the useful audit target is the message receiver in the privileged page. MDN's postMessage documentation advises verifying the sender's identity through the origin and, where appropriate, source properties, then checking the received message's syntax. In this case, Parameter's account shows why the receiving window's permissions deserve scrutiny even when the sending frame cannot directly read its parent.
According to Parameter's remediation timeline, OpenAI updated two web frontends and confirmed on October 26 that both rejected the reported cross-frame MathLive messages. Further public detail from OpenAI about the affected period and regression coverage would help establish the scope of the fix. For developers applying the finding elsewhere, the next check is specific: whether an untrusted child frame can still change HTML-bearing settings in a component running with the user's session.