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 #
| Question | Answer |
|---|---|
| Who found it? | Parameter's research team, write-up by Mukul Goyal, published October 28, 2026 |
| What did the victim have to do? | Open a public /share/<id> link; in the most stable version also click Preview once, later reproduced with automatic Preview |
| What could the code do? | Run as chatgpt.com , call authenticated backend APIs, read a private conversation, send data off-site |
| Severity | OpenAI raised it from P2 triage to P1 on October 21 |
| Fixed? | Per Parameter, confirmed October 26 for both web frontends |
| Bounty | $5,000 total, per Parameter |
| Exploited in the wild? | No evidence reported |
| OpenAI statement | None found; the account comes from the researchers and the bug bounty thread they describe |
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 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 #
| Date (2026) | Event |
|---|---|
| October 13 | Confirmed the MathLive message-to-HTML path against production code | | October 14 | Reproduced through the normal UI and upgraded the fixed alert to arbitrary JavaScript | | October 16 | Confirmed public-share delivery between separate accounts and workspaces with one Preview click | | October 17 | Confirmed automatic Preview from share navigation | | October 18 | Submitted to OpenAI's bug bounty program | | October 19 | Added the controlled private-chat disclosure proof | | October 21 | OpenAI reproduced it; severity raised from P2 to P1 | | October 22 | One web frontend fixed, second still updating | | October 23 | CSP changes blocked part of the chain | | October 26 | Both frontends rejected the reported messages; resolved; $5,000 total bounty |
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_leadpointed 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
lxgrlinked this to an earlier thread about remote file-system access via the ChatGPT desktop app and called the combination "pretty bad". - User
usernametaken29argued 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
dumberquestionsasked 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.
- 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.
- Never pass raw HTML through cross-window settings. Keyboard layouts and similar config should be data, not markup.
- Keep dynamically created documents sandboxed. If untrusted content can influence them, they must not inherit the main site's identity.
- 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
messagelistener 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 #
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.