A severe vulnerability in ChatGPT’s shared conversation system let attackers run custom JavaScript in another user’s session—merely by sending a specially crafted link. The flaw enabled access to private chats, conversations never shared with the attacker, and data exfiltration without needing stolen credentials.
The Technical Breach Explained
In late October 2026, OpenAI patched a bug reported through the Parameter security disclosure program. Rated “P1” and rewarded with a $5,000 bounty, the issue wasn’t due to weak passwords—it exploited an active browser session instead.
The exploit hinged on ChatGPT’s “HTML Preview” feature, designed to sandbox untrusted content safely. That feature generally isolates previewed HTML by rendering it inside a separate frame to prevent access to the main app. However, the embedded graph tool loaded a third-party math rendering library called MathLive. That library set up an event listener on the main page’s window to support its virtual keyboard. Crucially, it didn’t validate where messages were coming from or which window sent them.
An attacker could inject attacker-controlled HTML via keyboard layout messages, leverage an “innerHTML” call to place that content directly into ChatGPT’s main document, and then spin up an iframe using srcdocwithout sandbox constraints. Because this new frame inherited the trusted origin of ChatGPT’s domain, it got full access to the main page’s data. The final step was using a YouTube oEmbed endpoint that returned attacker-supplied JSONP callbacks—even when the callback parameter was invalid—effectively letting arbitrary script run as though it was part of chatgpt.com.
What Was Stolen & How OpenAI Responded
Once the malicious link was clicked—or in some cases, just when the conversation auto-loaded—the exploit’s code retrieved private conversations via authenticated APIs, even chats the attacker did not have permission to see. Sensitive session details from the frontend were exfiltrated back to a remote server via image requests.
OpenAI was notified on October 18; by October 21 the issue was confirmed and prioritized, and on October 26, fixes were deployed in the web frontend to block the problematic MathLive message events entirely. These patches ensured that only messages from trusted origins and verified source windows would be accepted.
Broader Context & Risk Factors
This vulnerability differs from previous bugs like the Gmail sandbox flaw, which depended on flawed internal storage access. Here, the attack spanned across browser boundaries through inter-frame messaging and used HTML injection plus iframe origin manipulation to break containment.
Because the preview was rendered from shared or public conversations, it was possible for attackers to combine untrusted content with trusted components to stage the attack. At least one version of the exploit triggered automatically without user interaction once the preview content loaded in accounts other than the one of the attacker.
On the disclosure front, this clean path from report to fix in under ten days underscores the value of responsible vulnerability reporting and bounty programs.
What to Watch Going Forward
As web applications increasingly rely on interactive content, cross-frame security demands rigorous source verification. The use of features like postMessage, innerHTML, srcdoc, and embedding third-party libraries call for careful isolation. Shared or public spaces must be treated as potential attack vectors, even when looking innocuous.
Users should be aware that simply clicking or opening links—even from conversations—may expose sensitive data if security boundaries aren’t watertight. Platforms that enable shared content previews must continually audit content pipelines.
This incident reveals how subtle design gaps—especially in web sandboxing and HTML rendering—can lead to full account compromise. The priority now is in making sure similar vector openings are closed everywhere before attackers test the limits themselves.
