Parameter Labs says a shared ChatGPT link could run attacker code via MathLive postMessage; OpenAI fixed, P1

Eight days from report to fix, and what the writeup does not count

Parameter Labs' writeup of 28 October 2026 dates its report to OpenAI's bug bounty to 18 October and OpenAI's confirmation that both ChatGPT web frontends rejected the reported messages to 26 October: eight days (derived). It also dates the first confirmation of the weak path against ChatGPT's production code to 13 October, so on the writeup's own dates the weakness was present in production for at least 13 days (derived) before it was confirmed closed. How long before 13 October it existed is not stated. This briefing rests on that writeup, read in full on 31 October 2026 between about 11:29 and 11:39 UTC, after reading the host's robots file, and read again before this briefing was finished. The Hacker News covered the story on 31 October; that page refuses scripts, was not fetched for this briefing, and nothing here rests on it except where marked.

What the dates do not establish is exposure. The writeup does not say how many people could have been reached, whether anyone other than the researchers used the chain, or whether any real person's conversation was read. It calls its proof controlled and describes "separate accounts and workspaces"; it does not say in so many words whose accounts those were. It says the code could take any action as the victim, and that is a claim from where the code ran, not something the writeup shows. The section on what was demonstrated sets the two apart.

Parameter's own site, read on 31 October, describes it as a seller of autonomous AI penetration testing and continuous security (parameter.ai), and the writeup is its own publication, so a finding of this size is also a shop window for it. That is not a reason to doubt the dates or the mechanism, which the writeup prints in detail. OpenAI runs the product and the bug bounty, and has an interest in how the severity and the reach are described. This briefing read no OpenAI page or statement about the issue. The P1 rating, the fix dates and the bounty figure are therefore the researchers' account of what OpenAI did.

Zoom

The chain, step by step: where the sandbox held and where it failed

The chain needs four ordinary things. ChatGPT can turn an HTML code block into a small working page with a Preview feature, and because that page can run anything it is run, the writeup says, in a restricted frame on a different web address. The browser treats that as another website, so code in it cannot read the signed in page around it. A conversation can also hold a graph, and the writeup says drawing the graph loaded a maths library called MathLive into the main page and installed a listener there for messages about MathLive's on screen keyboard. MathLive's own site calls the project "A web component to edit math, rendered with LaTeX" (mathlive.io). And a conversation can be published as a public share, reachable by a link.

The feature that joins them is postMessage, the browser mechanism that lets frames pass messages even when they cannot read each other. MDN's page on it, read 31 October, states the receiving rule plainly: "always verify the sender's identity using the origin and possibly source properties", and still check the syntax of what arrives. The writeup says MathLive's top level listener used an origin policy of none, which meant it accepted messages from any web address, and that it did not require the settings message to come from a previously approved window. A message of the public MathLive type could therefore replace the keyboard layout, and the layout was allowed to contain HTML. The Technical details section shows the type and action names the writeup prints.

When the keyboard was shown, the writeup says MathLive joined the layout into an HTML string and assigned it to innerHTML in the real ChatGPT page. A helper named createHTML looked as if it might clean the string. According to the writeup it did not: it marked the string as trusted and passed it through unchanged. Script tags inserted that way do not run, so the supplied HTML instead built an iframe that carried its own page in a srcdoc attribute, with no sandbox attribute. Because the main page created that frame, the browser gave it the chatgpt.com identity, and code inside it could reach the parent page.

That fresh document still had to run a script. The writeup says ChatGPT's content security policy blocked inline code but allowed scripts from YouTube, and that a YouTube oEmbed endpoint put a callback parameter into its response, which was served as JavaScript, even when it was rejecting the value with an error. The writeup prints the technique with a harmless marker value. This briefing does not reproduce the request form, because what matters for an allow list is the behaviour of the endpoint, and the writeup describes it.

Zoom

Delivery went through three versions, and the order matters. The first working version used a researcher controlled ChatGPT App as the sender, so a victim would have had to connect or invoke that App. A native HTML attachment could also send the messages, but when the conversation was exported as a public share the attachment stayed and the earlier graph did not, and without the graph nothing was listening. Putting a genuine graph and a later assistant authored HTML Preview in one ordinary public conversation kept the whole chain in the share link. The graph and the Preview loaded independently, so the message could arrive before MathLive was ready; the final version retried the same two messages for a limited period.

Three labels in this chain did the work of controls. "Sandboxed" was true of Preview, and the writeup says the sandbox itself worked, but a sandbox protects only what is inside it: the chain never had to break it, only to ask a trusted neighbour to act. "createHTML" sounds like sanitising; the writeup says it was an identity or Trusted Types wrapper, which can restrict who assigns to an HTML sink but does not make an attacker controlled string safe. And the content security policy was treated as the wall; the writeup says it stopped the researchers once more and was then passed through an allowed domain. In its words, CSP "should be a backup control, not the only barrier" once attacker controlled HTML reaches the main site.

What was demonstrated, between which accounts, and what is only claimed

The writeup shows, with a screenshot, a public share running code that the browser attributed to chatgpt.com and adding a banner to the real page. It then says the code read the session information already available to the page, called two conversation endpoints, listed recent conversations and requested message data for a selected private conversation. That conversation was, in its words, "unrelated to the malicious share and had never been shared with the attacker". It sent a small piece of the response to a server the researchers controlled, using an ordinary image request, and says it "deliberately" sent only that much.

Zoom

Zoom

The writeup's headline says account takeover. What the record shows is reading chat data as the victim, from a separate account, once the code ran as chatgpt.com. The step from there to any action is an inference from where the code ran, and a reasonable one: code on the real origin has the page's own authenticated access. But it is inference, and the writeup says as much when it writes that the reach was "not inherently limited" to the endpoints it used. No account setting, file or password change is shown.

What OpenAI did, according to the writeup, and what is not stated

Everything about OpenAI's response comes from the writeup's timeline and its section on the fix. OpenAI reproduced both the code execution and the private conversation proof. The fix was rolled out across two versions of ChatGPT's web frontend. On 22 October one was reported fixed while the second was still being updated; on 23 October content security policy changes blocked part of the chain while one update remained. On 26 October OpenAI confirmed that both versions now rejected the cross frame MathLive messages the report used, marked the issue resolved, and awarded a total bounty of $5,000.

That sentence is about the messages. It is not a statement that the design choices behind them changed. The writeup does not say whether the listener now checks the sender, whether the keyboard layout can still carry HTML, whether the frame MathLive builds is now sandboxed, whether the YouTube allowance in the policy was narrowed, or whether Preview, graphs or sharing changed at all. It does not say whether MathLive's maintainers were told or whether the library changed. Those are the questions a developer would ask, and the record leaves them open.

Zoom

The writeup names three design decisions that turned one mistake into a full exploit: MathLive accepted a state changing message without proving which frame sent it; the message format allowed raw HTML as keyboard layout data; and that HTML could create an unsandboxed document that inherited the chatgpt.com identity. It calls the YouTube response "the final workaround for CSP, not the root cause", and says blocking only that endpoint would have removed one path to JavaScript while leaving an untrusted Preview able to insert HTML into ChatGPT. Reading the three together, any one of them fixed would have broken this chain. That is this site's reading, and it is also why the checklist below asks for all three controls and not one.

What this adds to briefings already on the site

Our briefing on custom ChatGPTs and ClickFix found that the chatgpt.com address proved nothing about what sat behind it: the page held a message and a link, and the command was elsewhere. This writeup is the opposite case. Content in a shared conversation, on the researchers' account, ran with the chatgpt.com identity itself, so the address was the origin. The earlier case needed a person to paste a command. This one, on the writeup's account, needed an open link and at most one click.

The Pwn2Own Edge briefing covered a sandbox escape whose author says it used five logic bugs and no memory corruption. This is the same family: no memory bug, a boundary that held, and ordinary features that together did not. What it adds is a consumer AI product's share and Preview features, treated as a trust boundary and shown failing at the seams.

Technical details

The writeup prints message names, a deminified description of the listener, request lines, response headers and sizes. It prints no CVE id, no indicator of compromise, no detection rule, no query and no log signature, and it does not name the server the researchers used. Everything below is copied from the writeup, read on 31 October 2026, as short fragments. This briefing deliberately leaves out the complete messages, the payload and the callback request form: they are exploit material, and a defender does not need them. Nothing here is a proof of concept.

The first block is the identifiers of the vulnerable message interface. A team that ships MathLive, or any library with a window message listener, searches its own code for the type string and looks at what each action does with the data. The writeup says both fixed ChatGPT frontends now reject the cross frame messages its report used.

type: "mathlive#virtual-keyboard-message"
action: "update-setting"   (replaces the keyboard layout; the layout field is named layouts, with layers and markup)
action: "show"             (renders the keyboard)

The second block is the writeup's deminified view of the listener and of the sink. Read it for what is missing: the origin check calls a validator that, with the policy the writeup calls none, accepts every sender, and the message handler is given the sending window but, the writeup says, did not require it to be an approved one for the settings message. The last line is where the layout ended up as markup in the real page. A defender reviewing a listener checks both lines: who may send, and what the receiver does with the data.

if (event.data?.type !== "mathlive#virtual-keyboard-message") return;
if (!validateOrigin(event.origin, this.originValidator)) return;
this.handleMessage(event.data, event.source);

keyboardContainer.innerHTML = MathfieldElement.createHTML(keyboardHTML);

The third block is what the injected code asked ChatGPT for, as the writeup prints it. These are the web application's own endpoints, called from a frame with the same origin, so a request log by path alone would not tell them from normal use. The writeup gives no server side signal for telling them apart. It also says the code read the session access token and account identifier from the page and, before the outbound image request, cleared references to them. The angle brackets are the writeup's own placeholders, not values.

GET /backend-api/conversations?...&limit=20&order=updated&offset=0
GET /backend-api/conversations/<conversation-id>?num_turns=2

Authorization: Bearer <victim token>
ChatGPT-Account-ID: <victim account>
Accept: application/json

The fourth block is what the writeup observed from the YouTube endpoint: an HTTP 200 whose content type was JavaScript, with nosniff set, and, it says, no Cross Origin Resource Policy header. For a developer with an allow list the point is that an endpoint meant to return data returned something the browser accepted as a script. Check every third party domain in your script source list for any endpoint that echoes a parameter into a script typed response.

HTTP 200
Content-Type: text/javascript; charset=UTF-8
X-Content-Type-Options: nosniff

The sizes are the last artefact: the writeup says the final callback was 5,533 characters, the YouTube URL 7,309, the script element 7,337 and the final iframe markup 7,390. Derived by this site, and inference only: a script request to a video provider with a URL of about 7,300 characters, or an iframe with a srcdoc attribute and no sandbox attribute created in the live document, would be unusual in a page's own telemetry and in content security policy reports. The writeup does not offer these as detections.

For developers, in the order worth doing

Items 1, 3, 4, 5 and 8 follow the lessons the writeup states, reduced to a line, and item 1 is also what MDN says. The others are this site's guidance, drawn from the chain. The order is our judgement: it puts the controls that would each have stopped this chain first.

The question that exposes the gap

The writeup's own conclusion is that every individual feature looked reasonable and the flaw appeared only when they were combined in one page. Which two features in your product have never been tested together by someone who controls one of them, and which message listener in your page would still accept a sender you never meant to hear from?

Key facts