A shared ChatGPT conversation could become a route into a reader’s private chats—not because the reader disclosed them, but because attacker-controlled content crossed into the trusted, signed-in application. According to The Hacker News, researchers at Parameter demonstrated a vulnerability that allowed code delivered through a shared conversation to execute with the reader’s ChatGPT web-session access.
OpenAI has fixed the issue. The report says it was submitted on October 18, 2026, and that both affected frontend versions rejected the attack messages by October 26. For users, the immediate takeaway is reassuring: this was a server-side fix, with no software installation or account reset required. For developers, it is a warning about how interactive features can undermine an otherwise functioning sandbox.
What the researchers demonstrated
The attack started with an ordinary-looking public ChatGPT share link. Such a link could arrive in an email, workplace message, support ticket, or social post. The victim did not need to install software, join an attacker’s workspace, or enter credentials on a fake login page.
In the researchers’ most reliable version, the reader opened the shared conversation and clicked Preview. A later version caused Preview to open automatically, reducing the interaction to opening the link itself, according to the report.
Once running in the trusted application context, the researchers’ code used ChatGPT’s authenticated APIs to list recent conversations, retrieve a private conversation, and transmit a small excerpt to a researcher-controlled server. That distinction matters: the exposure was not limited to information visible on the current screen or to the conversation that had been shared.
The reported proof was a controlled test between separate accounts. Parameter did not report exploitation against real users. Demonstrating that private chats could be accessed establishes the seriousness of the flaw; it does not establish that a wider breach occurred.
Why a working sandbox was not enough
ChatGPT’s Preview feature can render HTML from a conversation as an interactive page. Because that content may contain code, it runs inside a restricted frame on a separate web address. According to the report, that isolation mechanism itself held.
The problem involved another feature in the same shared conversation: an interactive graph that loaded the MathLive library into the main ChatGPT page. MathLive installed a listener for messages associated with its on-screen keyboard. The researchers found that this listener accepted a relevant message without checking which frame had sent it, and that the message could contain raw HTML as keyboard-layout data.
This created a bridge from untrusted Preview content into the trusted application. The injected HTML created another frame that inherited the application’s origin rather than remaining isolated. The final execution step used a script loaded from YouTube, a source permitted by the site’s content security policy.
The important lesson is not that YouTube caused the vulnerability. As the report explains, that was a way around a final restriction. The underlying failure was allowing untrusted cross-frame input to introduce HTML into a privileged context.
What ChatGPT users should do now
The Hacker News reports that OpenAI reproduced both the code-execution behavior and the private-chat demonstration, escalated the issue from P2 to P1, and deployed the fix across two web frontend versions. Parameter published its findings on October 28, after remediation.
There is no reported requirement to reset your password, delete conversations, or install a patch in response to this issue. A password change would not address the application-level trust-boundary failure that enabled the demonstration.
Still, shared links deserve the same contextual scrutiny as other externally supplied material. An unexpected conversation link in a support request or direct message should not be treated as trustworthy simply because it points to a familiar service. Verify unusual requests through an established channel, particularly when they ask you to interact with embedded content.
For organizations, apply existing data-handling rules to AI conversations. Keeping credentials, production secrets, and unnecessary personal information out of chat histories reduces potential exposure across many incident types. That is general risk reduction, not evidence that this particular flaw exposed your organization’s data.
Practical lessons for application teams
This incident illustrates a browser application security failure, not simply an AI model following malicious instructions. The critical boundary was between untrusted rendered content and an authenticated web application.
Teams building interactive previews should review three controls together:
- Validate message provenance. Check both the expected sender origin and the sending window before acting on cross-frame messages. Validate the message structure and reject unexpected operations.
- Keep configuration separate from executable markup. Keyboard layouts and similar configuration inputs should not become arbitrary HTML in a privileged document. Prefer constrained data structures and safe rendering methods.
- Test the full feature combination. A preview sandbox, graphing library, and script allowlist can each appear reasonable in isolation while their interaction creates an exploitable path. Exercise those combinations during security testing.
Content security policy remains useful defense in depth, but it cannot replace a sound trust boundary. The durable lesson is to prevent untrusted content from acquiring application privileges in the first place—not merely to block the final script source used in one demonstration.