ChatGPT share-link account takeover: the postMessage bug, and how to secure your own listeners

Opening a public ChatGPT share link was enough to run an attacker's JavaScript as chatgpt.com in your signed-in session, read your private conversations and send them elsewhere. Parameter Labs reported the chain to OpenAI on 18 October 2026; OpenAI rated it P1, fixed it across two web frontends by 26 October, and Parameter published the write-up on 28 October (Parameter Labs).

The bug is not exotic. It is a message listener that trusted a frame it should not have, a setting that carried raw HTML, and an iframe created without a sandbox — three mistakes that are common in any app embedding third-party widgets or user-generated previews. This article walks through the chain, then shows the listener, iframe and Content Security Policy patterns that stop each link, with code you can drop into your own front end.

What did Parameter Labs find in ChatGPT?

A cross-frame takeover: content in ChatGPT's sandboxed HTML Preview could send postMessage instructions to the MathLive maths editor loaded in the main page, and MathLive turned one of them into HTML in the chatgpt.com origin. From there the payload read the session's access token and called ChatGPT's own conversation APIs as the victim. The researchers say they deliberately exfiltrated only a small piece of a response to prove the point (Parameter Labs).

There is nothing for ChatGPT users to patch: the fix was server-side and in the web app. What is worth your time is checking whether your own product has the same shape, because the researchers' point is that each component behaved "as designed" and the hole only existed where they met.

How the ChatGPT exploit chain worked, step by step

The attacker needed one public conversation containing two things: an interactive graph, which loads MathLive into the main page, and an HTML Preview, which runs in an isolated origin. Sharing that conversation delivered both to anyone who opened the link (Parameter Labs).

1. Cross-frame message. The Preview posts two messages to the top window: one replaces the virtual-keyboard layout with attacker HTML, the other tells MathLive to show the keyboard.
2. No sender check. The listener's origin policy was effectively none, and it did not confirm that update-setting came from a window it trusted.
3. HTML sink. MathLive assigned the layout markup to innerHTML. Its createHTML helper marked the string as trusted without sanitising it.
4. Unsandboxed frame. The injected HTML created an iframe with srcdoc and no sandbox attribute. Because the main page created it, it ran as chatgpt.com.
5. CSP bypass. The page blocked inline scripts but allowed www.youtube.com. A YouTube oEmbed endpoint echoed a JSONP-style callback into its error response, which loaded attacker code as a script.
6. Account access. The script read session bootstrap data from the parent, took the access token and account ID, and called the conversation list and detail endpoints.

All six steps are from the Parameter write-up; OpenAI reproduced both the code execution and the private-conversation read (Parameter Labs). MathLive has had HTML-injection bugs before: CVE-2025-29049 was an XSS through the \htmlData command, fixed in 0.104.0.

Why checking event.origin is not enough in a postMessage listener

Check the origin and the exact sending window, then validate the message's shape. MDN's guidance is blunt: if you do not expect messages from other sites, do not add a message listener at all, and if you do, "always verify the sender's identity using the origin and possibly source properties" — then "always verify the syntax of the received message" (MDN).

Origin alone fails in two common situations. If your app serves user content from a preview or sandbox origin, an origin allowlist that includes that origin also admits the attacker. And a frame sandboxed without allow-same-origin has an opaque origin, which arrives as the string "null" — so a listener that accepts "null" accepts every sandboxed frame on the page. Comparing event.source with the contentWindow of the one iframe you created pins the message to a single window.

// Accepts orders from any window in the page's frame tree.window.addEventListener("message", (event) => {  const msg = event.data;  if (msg && msg.type === "update-setting") {    keyboardEl.innerHTML = msg.layout;   // HTML chosen by the sender  }  if (msg && msg.type === "show") keyboardEl.hidden = false;});

const KEYBOARD_ORIGIN = "https://keyboard.example.com";const LAYOUTS = new Map([  ["numeric", buildNumericLayout],  ["greek", buildGreekLayout],]); window.addEventListener("message", (event) => {  if (event.origin !== KEYBOARD_ORIGIN) return;                 // who  if (event.source !== keyboardFrame.contentWindow) return;      // which window  const msg = event.data;  if (typeof msg !== "object" || msg === null) return;           // what  if (msg.type === "update-setting" && LAYOUTS.has(msg.layout)) {    keyboardEl.replaceChildren(LAYOUTS.get(msg.layout)());       // a name, never markup  } else if (msg.type === "show") {    keyboardEl.hidden = false;  }});

The second version carries a layout name, and the host builds the DOM itself. That removes the HTML sink altogether, which is the fix Parameter recommends: verify both event.origin and event.source before accepting state-changing instructions, and do not pass raw HTML through cross-window settings (Parameter Labs). When you send, give an exact target origin rather than *, so a frame that has been navigated elsewhere cannot read your message (MDN).

Library authors can check this in their own changelogs. MathLive 0.109.2 (28 April 2026) changed its virtual-keyboard message guard to check "the source window rather than only the top-level window" to fix a recursion bug in sandboxed iframes (MathLive changelog). The changelog does not describe that as a security fix, and it predates this report, so do not read it as the patch for this chain; if you embed MathLive's virtual keyboard, test what your version accepts.

A srcdoc iframe inherits your origin unless you sandbox it

An iframe built from srcdoc loads about:srcdoc, and without a sandbox attribute it runs with the embedding page's origin — which is how the injected frame in step 4 became chatgpt.com (Parameter Labs; MDN on iframe). Add sandbox to every frame whose content anyone else can influence.

function renderUntrusted(html) {  const frame = document.createElement("iframe");  // Opaque origin: no access to the parent DOM, cookies or storage.  frame.setAttribute("sandbox", "allow-scripts");  frame.setAttribute("referrerpolicy", "no-referrer");  frame.srcdoc = html;  previewEl.replaceChildren(frame);  return frame;}

Do not add allow-same-origin next to allow-scripts for content you do not control. MDN warns that for a same-origin embedded document the combination "lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all" (MDN). If the preview needs to talk to the page, use postMessage with the checks above, and remember that its origin will be "null", so identify it by event.source.

Why the Content Security Policy did not stop the attack

Because it was an allowlist. The page blocked inline scripts but trusted every script on www.youtube.com, and one YouTube endpoint would wrap attacker-chosen text in a callback (Parameter Labs). Google's strict CSP guide says allowlist policies "can be bypassed by attackers", citing research into exactly this class of trusted-host gadget, and recommends a nonce- or hash-based policy instead:

Content-Security-Policy:  script-src 'nonce-{RANDOM}' 'strict-dynamic';  object-src 'none';  base-uri 'none';

With a nonce, a script loads only if the tag carries this response's random value, or was created by a script that did; a JSONP URL on a host you trust gets no special pass. The nonce must be fresh on every response (web.dev). To close the innerHTML sink as well, the Trusted Types API lets a CSP require that DOM sinks receive values from a policy you wrote. MathLive's createHTML shows the trap: a policy that marks a string as trusted without sanitising it satisfies the browser and protects nothing.

// Served with: Content-Security-Policy: require-trusted-types-for 'script'import DOMPurify from "dompurify"; export const htmlPolicy = trustedTypes.createPolicy("app-html", {  createHTML: (input) => DOMPurify.sanitize(input),   // sanitise, don't just wrap}); // keyboardEl.innerHTML = untrusted;                 // now throws a TypeErrorkeyboardEl.innerHTML = htmlPolicy.createHTML(untrusted);

Which defence stops which step

Any one of the first three controls below would have broken the chain on its own; the rest are there for the day one of them slips. That is why Parameter frames CSP as defence in depth rather than the barrier: blocking one YouTube endpoint leaves the injection path open for the next gadget.

How to audit your own front end for postMessage bugs

Start with a search, because the risky code is small and easy to find. List every message listener, every srcdoc and every iframe you create from script, then ask of each listener: which window is it meant to hear, and does it check that window?

rg -n "addEventListener\(\s*['\"]message['\"]|onmessage\s*=" src/rg -n "srcdoc|createElement\(['\"]iframe" src/rg -n "innerHTML|outerHTML|insertAdjacentHTML" src/

Do the same for third-party scripts you load into the top page — maths editors, chat widgets, payment and analytics SDKs — since a vendor's listener runs with your origin. Then test the combinations, not the features: share a document containing every embed type, open it signed in as a second account, and post messages at the top window from the browser console inside each frame. Parameter's last recommendation is the one that generalises: treat anything a user can share as attacker-controlled input (Parameter Labs).

The one thing to remember

A message listener is an API endpoint with no authentication unless you write it. Give it an exact sender — origin and window — accept data rather than markup, and sandbox any frame whose contents someone else can shape; the strict CSP is there for the day one of those slips.

Sources and further reading

• Parameter Labs: Do the Math — How We Took Over ChatGPT Accounts
• MDN: Window.postMessage(), security concerns
• MDN: the iframe element, srcdoc and sandbox
• web.dev: Mitigate cross-site scripting with a strict Content Security Policy
• Weichselbaum et al.: CSP Is Dead, Long Live CSP!
• MDN: Trusted Types API
• MathLive changelog and CVE-2025-29049
• Hacker News discussion