ChatGPT Share-Link Account Takeover: How One Public Link Ran Code as chatgpt.com

A public ChatGPT share link could, until October 26, 2026, run an attacker's JavaScript inside the signed-in session of whoever opened it, according to a write-up by the security firm Parameter. The researchers say the code ran as chatgpt.com, could list a victim's private conversations, read one that had never been shared, and send data to an outside server. OpenAI classified the report P1, fixed it across two versions of its web frontend, and paid a $5,000 bounty. This is the researchers' account; OpenAI has not published its own advisory that we could find.

If you want the short version: nobody is reported to have been hit in the wild, the hole is closed, and the lesson is about stacking small features. The longer version is worth reading because the chain is a clean example of how sandboxes fail at the seams. We also cover the wider pattern of agents and chat products leaking through shared surfaces in our posts on Claude shared chats indexed by Google and the ChatGPT Chrome extension permissions.

TL;DR: what is claimed and what is confirmed

Agents that act on your behalf need rules. See how explainx helps secure your agents →

How the chain worked, step by step

Parameter's write-up frames the story as three harmless-looking features that combined badly: an interactive graph, an HTML Preview, and a Content Security Policy that trusted YouTube.

Step 1: The Preview sandbox held, but it could still send mail

ChatGPT can render an HTML code block as a working page using Preview. Because that code is arbitrary, it runs in a restricted frame on a different web address. The researchers confirm the isolation worked: Preview code could not read the parent page's document.

What it could do is call postMessage, the browser API that lets frames exchange messages even when they cannot read each other. Parameter describes it as a mail slot: safe only if the receiver checks who sent the letter.

Step 2: MathLive trusted the wrong sender

When a conversation contained a graph, ChatGPT loaded a math library called MathLive. Parameter says that loading it also installed a listener in the main page for messages that control MathLive's on-screen keyboard. That listener used an origin policy of "none", so it accepted messages from any web address, and it did not require the "update setting" message to come from a window it had approved.

The Preview sent two messages: one replacing the virtual keyboard layout with the attacker's HTML markup, and one telling MathLive to show the keyboard. The library then joined the layout into a string and assigned it to innerHTML in the real ChatGPT page. A helper called createHTML looked like a sanitizer but, per the write-up, acted as an identity wrapper that passed the string through untouched.

Step 3: From HTML to a document that inherits chatgpt.com

Scripts inserted through innerHTML do not run, so HTML injection alone was not enough. The researchers used an iframe with a srcdoc attribute. MathLive inserted it into the main document without a sandbox attribute, so the new document was created by the ChatGPT page and inherited the https://chatgpt.com identity. Code in it could reach the parent.

Step 4: The CSP bypass through YouTube

ChatGPT's Content Security Policy blocked inline scripts, but allowed scripts from YouTube. Parameter found that YouTube's oEmbed endpoint accepted a JSONP-style callback parameter and echoed it into the response before returning a validation error. Ending the callback with ;void made the error object harmless, so the browser loaded the response as a script and ran the attacker's code. The write-up is explicit that this was the last workaround, not the root cause: blocking that endpoint alone would have left an untrusted Preview able to insert HTML into ChatGPT.

Step 5: Turning a lab bug into one public link

The first version needed a researcher-controlled ChatGPT App as the sender, which would have required a victim to connect it. Parameter then put both pieces into one ordinary public conversation: a genuine graph that initialized MathLive, and a later assistant-authored HTML Preview that sent the messages. The resulting /share/<id> link preserved the whole chain, deliverable by email, chat, a support ticket or a social post. They reproduced the automatic-Preview variant three times in a separate account, with the alert appearing after roughly 4.5 seconds.

What an attacker could actually reach

The payload read the session bootstrap data already present in the page and called ChatGPT's conversation endpoints as the victim. Parameter lists a conversation-list request and a detail request for one conversation, then fired a plain image request to a server it controlled, deliberately sending only a small piece of the response. The write-up's claim is broader: because the code ran with the web app's authenticated access, any action available to the normal frontend was in scope.

That is the important framing. An alert box proves little; same-origin JavaScript in a logged-in AI product is a window into chat history, uploaded files, connected apps and memory. If you have connected mail or file plugins, as in our guides to ChatGPT iCloud plugins and ChatGPT Sites hosting plugins, the blast radius of any session compromise grows accordingly.

Timeline from Parameter's write-up

The gap between report and full fix was eight days, with a partial CSP mitigation in the middle. That is a normal cadence for a P1 across two frontends, though readers should note the exploit was reproducible on production for at least that window.

What developers are saying

The Hacker News thread reached 52 points. Commenters raised a few distinct points, all as their own opinions rather than verified facts:

• User yellow_lead pointed out that the exploit needs a click on a link, but still found the $5,000 bounty low and worried researchers may stop reporting.
• User lxgr linked this to an earlier thread about remote file-system access via the ChatGPT desktop app and called the combination "pretty bad".
• User usernametaken29 argued that large codebases grow more bug surface, and used it to question how much agent-written code is reviewed. That is opinion, not something the write-up claims.
• User dumberquestions asked whether the blog was written by a human, a reminder that the original post's style drew its own skepticism.

None of these change the technical facts, but the bounty debate is useful context: the reward scale for P1 bugs in AI products is a recurring argument, and we saw similar questions in our coverage of ChatGPT Dots and unapproved actions.

Why this matters beyond one bug

Four design lessons stand out, and they apply to anyone building agent or chat products with previews, artifacts or shared pages.

1. Authenticate both origin and source window. Parameter's recommendation: a message receiver should check the sender's web address and the exact window it granted permission to before accepting state-changing instructions.
2. Never pass raw HTML through cross-window settings. Keyboard layouts and similar config should be data, not markup.
3. Keep dynamically created documents sandboxed. If untrusted content can influence them, they must not inherit the main site's identity.
4. CSP is a backup, not the barrier. Once attacker HTML reaches the main page, an allow-listed third-party endpoint can become the script source.

This is the same family as the prompt-level attacks in our guide to indirect prompt injection, except the exploit here is classic web security: no model had to be fooled. AI products now ship Preview panes, artifacts, shared chats and plugin hosts, each a new trust boundary. See also how a poisoned extension reached developers in the trojanized Claude Code extension case and how repos leaked through agent workflows in gitlost.

A crooked hook catching a blank instruction card, illustrating how untrusted content can hijack a trusted AI interface

What to do now

You do not need to panic, but a few cheap steps are reasonable:

• Be wary of unknown share links. Shared AI conversations are untrusted input. Open them in a separate browser profile or a signed-out window when you do not know the sender.
• Review your account. Check recent conversations and connected apps in ChatGPT settings, and revoke plugins you do not use.
• Sign out of other sessions if you opened unfamiliar shares in October and want extra assurance.
• Do not rely on the share feature's reputation. Disable sharing for sensitive chats and delete shares you no longer need.
• For teams running agents, put controls around what agents can do when they handle untrusted content. AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions.
• For builders, audit every message listener in your own app, and check what your CSP allows. Allow-listing a large third-party host is allow-listing every endpoint on it.

Open questions

• OpenAI has not published a statement or advisory that we could find, so the P1 classification and fix dates come from Parameter's account.
• Whether any attacker used the chain before the fix is not reported.
• It is unclear whether MathLive itself has been changed upstream; the write-up describes the receiver behavior in ChatGPT's production code, not a library advisory.
• Parameter withheld nothing about the chain's mechanics, which means copycat variants in other products that embed the same library are plausible. If you ship MathLive, review how your app handles its virtual keyboard messages.

We will update this post if OpenAI or the MathLive maintainers publish their own account.

Related reading

• Claude shared chats and artifacts indexed by Google
• ChatGPT Chrome extension: permissions and risks
• Indirect prompt injection explained
• Trojanized Claude Code extension: what is confirmed
• gitlost: GitHub agentic workflows and private repos
• ChatGPT locked chats: what they do and do not protect
• Sources: Parameter research write-up, MathLive on GitHub, Hacker News discussion

Details are accurate as of October 31, 2026, based on the researchers' published account. We will correct this post if OpenAI publishes a different timeline.