Field noteOct 31, 20265 min read1 source

Do the Math: How We Took Over ChatGPT Accounts

In one minute

Parameter says it found a way for a malicious public ChatGPT conversation share to execute JavaScript in a recipient’s signed-in ChatGPT session. The chain crossed an HTML Preview sandbox through a MathLive message handler and an unsandboxed frame. OpenAI fixed the issue on October 26, 2026, and classified it as P1; the case matters to teams that render untrusted content inside trusted web applications.

What changed: Parameter reports a newly fixed P1 vulnerability chain that could take over ChatGPT accounts through a shared conversation link.

What happened

In a report by Mukul Goyal, Parameter describes a vulnerability chain discovered in October 2026. An attacker could create a conversation containing a graph and an HTML Preview, publish it with ChatGPT’s standard sharing feature, then send the resulting link to a target. According to Parameter, opening the link was the only action required of the victim: no app installation, project membership, code pasting, or developer tools were involved. Parameter says the attacker-controlled code ran in the victim’s authenticated ChatGPT session and could call ChatGPT APIs as that user.

The chain began with two features in the same conversation. ChatGPT’s HTML Preview ran arbitrary code in a restricted frame on a separate website, which prevented that code from directly reading the parent page. The graph loaded MathLive, a math library that also installed a postMessage listener in the main ChatGPT page for virtual-keyboard controls. Parameter found that the listener accepted messages without an origin check and did not require the sender to be an approved window. The Preview could send messages that changed the keyboard layout and then opened it. MathLive rendered the supplied layout as HTML in the main page. Parameter says a helper that appeared to sanitize the content instead marked it as trusted and passed it through.

The next step was an iframe using srcdoc, inserted into the main document without a sandbox attribute. Although scripts inserted through innerHTML do not run automatically, the iframe supplied a new document in which external scripts could execute. Because the main ChatGPT page created it, the frame had the chatgpt.com web identity and could access its parent. ChatGPT’s Content Security Policy blocked inline JavaScript, but Parameter says it allowed scripts from YouTube. The researchers used YouTube’s oEmbed endpoint, which supported a JSONP-style callback: its response included the supplied callback before returning a validation error. The callback could therefore run as a script from an allowed domain.

Parameter says the first working approach depended on a researcher-controlled ChatGPT App, which made it unsuitable as a simple link attack. A native HTML attachment could send the messages, but the graph that initialized MathLive did not survive as part of the shared conversation when they tested that route. The researchers then put both elements in one public conversation: a genuine graph loaded MathLive, and a later assistant-authored HTML Preview sent the messages. The public share preserved the full chain. Parameter reports that the code enumerated the victim’s conversations, retrieved content from a private conversation never shared with the attacker, and sent data to an external server. OpenAI fixed the issue on October 26 and rated it P1. The supplied source excerpt also reports that the issue was raised on October 18 and that a $5,000 bounty was paid.

What the archive adds

Our archive has related ChatGPT coverage, but not prior coverage of this vulnerability. ChatGPT adds account switching on iOS and Android concerns account access and sessions, not this exploit. This is a new security event, not a restatement of that product update.

Trend signal

This case supports agent security moves to runtime boundaries: controls that constrain what code can access matter more than a promise that a preview is isolated. Here, the browser sandbox was undermined by a trusted parent-page listener and an unsandboxed frame created across that boundary. The pattern is relevant to web applications embedding generated or otherwise untrusted content.

Why now

Parameter dates its discovery to October 2026 and says OpenAI fixed the issue on October 26, classifying the report as P1. The report is therefore a recently disclosed account of a flaw the vendor says is fixed; it does not establish any continuing exposure after that remediation.

Why it matters

The lesson is not simply to add a sandbox attribute to a preview. An application can isolate one frame and still create a route back into its privileged page through message handlers, rendering code, or frames it creates on behalf of the content. Teams building AI-assisted editors, previews, and document viewers should treat every bridge between untrusted content and the parent application as part of the security boundary. That includes validating both the sender’s origin and window, restricting message types and payloads, and avoiding insertion paths that turn attacker-controlled markup into trusted HTML. Parameter’s example also shows that CSP is only one layer: a policy that permits a third-party script origin may interact with callback behaviors in unexpected ways. The report does not imply that every HTML preview is vulnerable, but it demonstrates why boundary review must follow the complete data and execution path, not just the first sandbox.

Limits and uncertainty

The supplied report is Parameter’s account of its own research. It does not independently establish how many users, if any, were affected before the fix, whether the chain was exploited outside the researchers’ demonstration, or the exact deployment scope and timing of remediation. The source says OpenAI fixed the issue on October 26, 2026, but the supplied material does not detail the code changes or provide an independent retest. Nor does it establish that the same MathLive, YouTube JSONP, or iframe behaviors remain exploitable elsewhere. The reported capabilities demonstrate impact in the researchers’ test, not evidence of real-world compromise.

Skill to build now

This week, map every postMessage listener in a preview or embedded-content flow. For each listener, verify that it checks the expected origin and source window, accepts only narrowly defined message types, validates the payload schema, and cannot pass attacker-controlled markup into privileged rendering paths. Then test whether any frame created in response to a message inherits the parent application’s origin or lacks an appropriate sandbox.

Reader takeaway

A sandbox is not a complete security boundary if untrusted content can persuade trusted code in the parent page to render HTML or create a privileged frame. Audit the bridges, not just the box around the preview.

Evidence / sources

  1. 1parameter.ai/labs/we-found-a-gap-at-openai
All Field Notes

Next reads

Read next

Open the graph
  1. 01topicAgent SecurityExplore the agent-security topic hub.
  2. 02topicSandboxExplore the sandbox topic hub.
  3. 03archiveField NotesOpen the latest editorial analysis.
  4. 04source ledgerSource LedgerInspect the public source evidence graph.
Who read this page?Machine requests, hidden until opened

Loading the privacy-safe route aggregate...

Open the JSON contract