ChatGPT Share Link XSS: How One Shared Chat Could Run Code in Your Session

A public ChatGPT share link could run an attacker's JavaScript inside the signed-in session of anyone who opened it. Security firm Parameter published the chain on October 28, 2026: the code ran as chatgpt.com, listed the victim's conversations, read a private chat and sent part of it to a server the researchers controlled. OpenAI classified it P1, fixed it on October 26 across two versions of its web frontend, and paid a total bounty of $5,000. This is a ChatGPT web bug, not a coding-agent CLI bug, but the mechanism matters to anyone who opens AI-generated transcripts and previews, so it is worth understanding.

What happened with the ChatGPT share link XSS?

The write-up describes an attacker who builds a malicious conversation, publishes it with ChatGPT's ordinary sharing feature and sends the /share/<id> link by email, chat, a support ticket or a social post. When the victim opens it, the payload runs with the victim's authenticated web session. No app install, project invitation, pasted code or developer tools are required.

The researchers confirmed three things against their own accounts: the code could enumerate the conversation list, it could fetch the content of a private conversation never shared with the attacker, and it could send data from that conversation to an external server. Because the code ran as the web application, Parameter argues its reach was not limited to those endpoints: other data and account actions exposed to the frontend sat inside the same boundary.

How the chain works, step by step

Every link in the chain was a feature that looked harmless on its own. Parameter's walkthrough breaks it into these stages.

1. Preview is sandboxed, as designed. ChatGPT can turn an HTML code block into a small live page through its Preview feature. Because that page may hold arbitrary code, it runs in a restricted frame on a different web address. It could not read parent.document, the signed-in ChatGPT page around it.
2. A graph installs a listener. A normal interactive graph in the conversation loaded a math library called MathLive. Loading it also registered a message listener in the main page for messages about MathLive's on-screen keyboard.
3. postMessage is the mail slot. The browser stops two frames reading each other, but postMessage lets them pass messages. That is safe only when the receiver checks who sent the message. Parameter found MathLive's top-level controller used an origin policy of none, so it accepted messages from any address, and it did not require the update-setting message to come from a previously approved window.
4. Keyboard layouts could carry HTML. The Preview sent two messages: one replaced the virtual keyboard layout with attacker HTML, the second told MathLive to show the keyboard. MathLive joined the layout into a string and assigned it to innerHTML in the real ChatGPT page. A helper named createHTML looked like a sanitizer but marked the string as trusted and returned it unchanged.
5. An unsandboxed srcdoc frame inherits the origin. Scripts inserted through innerHTML do not run, so the HTML instead created an <iframe srcdoc>. MathLive inserted it without a sandbox attribute, and because the main page created it, the browser gave it the https://chatgpt.com identity. Code inside could now reach the parent.
6. The CSP stopped inline scripts, but allowed YouTube. ChatGPT's Content Security Policy blocked inline JavaScript while permitting scripts from YouTube. YouTube's oEmbed endpoint accepted a JSONP-style callback parameter and echoed it into the response even when it then returned a validation error. Ending the callback with ;void made the appended error object harmless, so the browser loaded the response as an allowed script and ran the attacker's callback.
7. Authenticated API calls. The same-origin frame read the page's bootstrap data, took the session token and account ID, and called ChatGPT's conversation APIs as the victim, then made an ordinary image request to the researchers' server carrying a small selected value.

Parameter summarises the flow in five steps: the attacker publishes a conversation, the victim opens the public share, the HTML Preview crosses into the main chatgpt.com page, JavaScript runs in the victim's signed-in session, and any action on chatgpt.com is available as the victim.

Why a single share link was enough

The first working version used a researcher-controlled ChatGPT App as the sender, so a victim would have had to connect it first. The delivery trick that made it a real-world attack was putting both pieces into one ordinary public conversation. A genuine graph initialized MathLive in the main page, and a later assistant-authored HTML Preview sent the two messages. With a native HTML attachment, the public share kept the attachment but dropped the earlier graph, so nothing was listening for the messages. Placing the graph and the Preview in one conversation preserved the whole chain in the /share/<id> link.

Parameter observed two behaviours. In the most stable reproduction the victim opened the share and clicked the normal Preview button once. The researchers later marked the HTML block as previewable so ChatGPT opened it automatically, which meant opening the link was the only action. They reproduced the automatic path three times in a separate account, including after a hard refresh, with the proof alert appearing after roughly 4.5 seconds. Because the graph and the Preview load independently, the payload retried its messages for a limited period to win the race.

Timeline and what OpenAI changed

According to Parameter's timeline, the production path was confirmed on October 13, the report went to OpenAI's bug bounty on October 18, and OpenAI reproduced it on October 21, raising severity from an initial P2 triage to P1. On October 22 one web frontend was reported fixed while the second was still being updated; on October 23 CSP changes blocked part of the chain. On October 26 OpenAI confirmed both frontends rejected the cross-frame MathLive messages and resolved the report, with a total bounty of $5,000. Secondary coverage, such as this summary on DEV Community, repeats the same dates and the same conclusion that the Preview sandbox itself held.

Parameter is explicit that blocking the YouTube endpoint alone would not have been a fix: the root problem was an untrusted Preview being able to make a trusted component insert HTML into the main page. MathLive is an open-source library, and the source describes the library behaviour as observed in ChatGPT's production bundle; we have not independently reproduced it and the sources reviewed do not say whether the library itself changed.

What this means if you run AI coding agents

You probably do not use ChatGPT's share feature as part of your coding-agent workflow, but the pattern repeats across the tooling you do use. Preview panes, rendered artifacts, exported transcripts and "open this session" links all take content an agent or another person produced and render it next to something authenticated.

• Treat a shared transcript as untrusted input. A link to someone else's AI conversation is a document that can contain markup, scripts, and instructions. Open unknown ones in a separate browser profile or a logged-out session.
• Keep sessions short and reviewable. In ChatGPT, review active sessions and shared links in your account settings, and delete shared links you no longer need.
• Remember that preview features share a surface with your account. We covered the same class of problem in the Claude Code Desktop preview pane in SneakPeek, in embedded-browser flaws across Cursor, Copilot, Claude and Codex, and in the Claude session-bridge token disclosure.
• If you build products with a preview or embed feature, take Parameter's lessons literally: authenticate both event.origin and event.source on every state-changing postMessage receiver, never let cross-window settings carry raw HTML, keep dynamically created documents sandboxed, and treat CSP as defence in depth rather than the only barrier.
• If you opened a suspicious share link before October 26, there is no published indicator to search for. Reasonable precautions are signing out of active sessions, reviewing recent conversations for anything unfamiliar, and rotating anything sensitive you pasted into ChatGPT.

What Beam can and cannot do here

Beam watches what local coding agents do: hook-based checks on Claude Code and Codex tool calls, scans of skills and MCP configs, and redaction before storage, all on-device. This bug was JavaScript running inside a web page in your browser, not a tool call by an agent, so those hooks never see it, and Beam would not have blocked it. Updating the service (done by OpenAI) and reducing what a session can reach are the effective defences. If you want the layer Beam does offer for browser AI assistants, see Sentinel in the browser; it is a pause-and-block extension for assistant interactions, not a generic XSS defence.

Where this fits in October's attack picture

The month has been full of cases where a trusted component was made to render something it should not have, from Claude preview panes to shared artifacts. For the wider picture, see the October 2026 attacks timeline and the earlier look at shared artifacts and filesystem export claims in Meta's Muse agent. The technical detail above comes from Parameter's own report.

Frequently asked questions

What was the ChatGPT share link vulnerability?

Parameter found that a public ChatGPT share link could run attacker JavaScript as chatgpt.com in the signed-in session of whoever opened it. The chain combined the HTML Preview feature, the MathLive graph library and a Content Security Policy bypass.

Has it been fixed, and do I need to update anything?

OpenAI fixed it on October 26, 2026 across two versions of its web frontend and classified it P1. The fix is server-side in the web app, so there is nothing for users to install.

Was it exploited in the wild?

Parameter reports a controlled proof of concept only, and the sources reviewed describe no real-world abuse. OpenAI has not published a statement about past exploitation that we found.

What could an attacker do with it?

In the proof, injected code listed the victim conversations, read a private chat that had never been shared, and sent a small piece of it to an external server. Parameter says any action the ChatGPT frontend could perform was in reach.

Does this affect Claude Code, Codex or other coding agents?

The flaw was in the ChatGPT web app, not in a coding agent CLI. The lesson carries over: shared or exported agent transcripts, previews and rendered artifacts are attacker-controlled input and deserve the same caution as any untrusted file.

How do I reduce this kind of risk?

Open shared AI conversations from unknown senders in a separate browser profile or logged-out session, keep the browser updated, and review the active sessions and shared links in your account settings.

Related reading

• SneakPeek: the Claude Code Desktop preview pane flaw
• Embedded browser flaws in Cursor, Copilot, Claude and Codex
• Claude session-bridge tokens and artifact uploads
• Sentinel: Beam in the browser
• Primary source: Parameter, "Do the Math: How We Took Over ChatGPT Accounts"
• Secondary: The 420 summary

Details are accurate as of October 31, 2026, based on Parameter's published report. Beam is a local prototype and its features are described as documented; we will update this post if OpenAI publishes its own account.