Image: Parameter
Why it mattersA trusted assistant can carry an attack. Any team that lets a model render HTML on its own page needs to check who sent each cross-frame message.
Opening a shared ChatGPT link should feel as safe as opening a document a friend sent you. Parameter, a security research firm, reports that it was not. The firm found a chain of bugs. The chain let any public ChatGPT share run code inside the reader's signed-in session.
OpenAI fixed the issue on 26 October and classified it as P1, Parameter says. The firm says it received a bounty of $5,000 for the report. Parameter published the report on 28 October.
What the attack did
Parameter writes that an attacker could create a conversation in their own account. They publish it as a normal ChatGPT share, then send the link. When the victim opened the share, code ran as chatgpt.com with the victim's web session.
The payload could then call ChatGPT's own authenticated APIs as the victim. Parameter says it read a list of the victim's recent conversations. It then pulled the full content of a private chat that had never been shared. It sent part of that content to a server the firm controlled. The victim had to click only the shared link, Parameter says.
The chain, in plain terms
The problem was not one bug in one place. It was five normal features joining up:
- A ChatGPT share can contain a graph. Drawing the graph loaded a math library called MathLive in the main page.
- MathLive listened for cross-frame messages that changed its on-screen keyboard. One of those messages let the sender replace the keyboard layout with raw HTML. Parameter says MathLive did not check which frame sent the message.
- A ChatGPT share can also contain an HTML Preview. The Preview runs in a sandbox on another address. It cannot read the main page. But it can send a message to it.
- The Preview sent two MathLive messages. The second told MathLive to show the keyboard. MathLive put the attacker's HTML straight into the main ChatGPT page.
- That HTML included an iframe with
srcdocand no sandbox. The browser gave the new frame the chatgpt.com identity. The frame then loaded a script through YouTube's oEmbed endpoint, which ChatGPT's content security policy allows. The script ran as chatgpt.com.
Every feature by itself looked fine, Parameter says. The isolation only broke when they ran on the same page.
What OpenAI fixed
OpenAI reproduced the proof of concept, Parameter writes. The fix went out across two versions of the ChatGPT web frontend. On 26 October, both versions rejected the cross-frame MathLive messages the report used. Parameter dates its first working chain to 13 October and its report to 18 October.
What a team building AI products takes from this
Any product that lets a model show arbitrary HTML in its own page sits in the same shape ChatGPT did. The lessons Parameter draws are specific. A message receiver that changes state has to check two things. It has to check the sending frame's address. It also has to check the exact window that was given permission. Cross-window settings must not accept raw HTML. A frame built from attacker-influenced content must stay sandboxed. That is true even when the parent trusts the component that created it. Content security policy is a backup, not the only line.
The common thread is that trust in a model's output cannot be a global property of the page. Every path from the model to the DOM is its own boundary and needs its own check.
Source
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.
