A public ChatGPT share link could run attacker code inside your signed-in session. Here is what actually broke, why it matters to a business that runs on AI, and what to fix this week.
Someone sends you a link. It looks like every other shared ChatGPT conversation you have ever opened: same domain, same layout, a chat about a graph and a bit of HTML. You click. You might even click the little Preview button out of curiosity.
That was the whole attack. According to research firm Parameter, that single click let their code run inside your authenticated ChatGPT session, with the same access as the real ChatGPT site. From there it listed recent conversations, opened a private chat that had never been shared with anyone, and sent part of it to a server the researchers controlled. Their own summary is blunt: they could perform any action on behalf of the victim's ChatGPT account.
Parameter reported the flaw through OpenAI's bug bounty on October 18, 2026. OpenAI fixed it on October 26 and rated it P1, its most serious category. There is no evidence of real-world use, and the proof was run between the researchers' own accounts. The patch is shipped. The pattern, though, is not going anywhere.
It started with a graph and a keyboard
Here is the part worth reading twice, because it explains why "we patched the bug" is never the end of the story.
ChatGPT can turn a block of HTML in a conversation into a small working web page through its Preview feature. Because that page can contain arbitrary code, OpenAI runs it in a restricted frame on a different web address. On its own, that isolation held up: code inside the preview could not read the main ChatGPT page.
The conversation also contained an ordinary interactive graph. Behind the scenes the graph loaded MathLive, a math typesetting library. Loading it did more than draw a curve. It installed a listener in the main ChatGPT page for messages about MathLive's on-screen keyboard.
Browsers call that API postMessage. Think of it as a mail slot between two frames that are otherwise sealed off from each other. That is safe only if the receiver checks who is posting.
MathLive's listener used an origin policy of none, which is a polite way of saying it accepted messages from any web address. The payload it accepted updated the virtual keyboard layout, and that layout was allowed to contain HTML. When the keyboard opened, the library joined the supplied layout into an HTML string and assigned it to innerHTML in the real ChatGPT page. A helper function named createHTML looked like it sanitised the value. It did not. It marked the string as trusted and passed it through unchanged.
Two unrelated features. One trusted receiver, installed by a graph. One untrusted sender, supplied by a preview. A bridge across the sandbox.
From a stray message to full account access
Script tags inserted through innerHTML do not run on their own, so the researchers still needed to light the fuse. They used an iframe with a srcdoc attribute, inserted without a sandbox attribute. That created a fresh document where an external script could execute, and because the main ChatGPT page had created the frame, the browser gave it the https://chatgpt.com identity. Code inside that frame could now reach the parent page.
ChatGPT's Content Security Policy blocked inline JavaScript, which is exactly what a good CSP is for. It did, however, allow scripts from YouTube. YouTube's oEmbed endpoint supported a JSONP-style callback parameter and, helpfully, placed the callback into its error response before validating it. Because YouTube was already on the allowlist, the browser loaded that response as a script and ran the attacker's callback inside the new frame.
Result: arbitrary JavaScript running as chatgpt.com, inside a signed-in session, reachable by a link.
Parameter then made the delivery boring, in the best possible way for an attacker. They put the graph and the preview into one ordinary public conversation, exported it as a normal /share/<id> link, and sent it the way anyone sends a shared chat: by email, in a chat message, in a support ticket, as a social post. In the most stable version the victim clicked Preview once. In a later version the preview opened by itself, and the alert fired after roughly 4.5 seconds. Opening the link was the only click.
No app install. No workspace join. No consent screen. No phishing page that looks almost right.
Why your business should care even though it is patched
It is easy to file this under "OpenAI bug, already fixed, move on". That reading misses the three things that actually put your organisation at risk.
First, the attack surface was a feature you are encouraged to use. Sharing a conversation is a collaboration feature, and collaboration features are usually trusted by default. Here it was a link that carried executable code into an authenticated session.
Second, the trust boundary was the AI session itself. Once the code ran, it did not need to scrape pixels off the screen. It called ChatGPT's own authenticated APIs as the signed-in user. Any control that watches what a human clicks on the page sees nothing.
Third, one sandbox escape in one product is rarely an isolated failure. This chain is a tour of ordinary development shortcuts: a message listener with no sender check, a sanitiser that marked input trusted instead of cleaning it, an iframe created without a sandbox, and a CSP allowlist wide enough to be useful to an attacker. Those patterns exist in every codebase that wired up an integration in a hurry. Ours included.
The uncomfortable part: your AI session is your whole context
Ask yourself what is inside your team's AI chats. A client's architecture. A contract clause being rewritten. A migration plan. Credentials pasted once and forgotten. A pricing model someone was still deciding on.
That is not a chat log. That is the densest concentration of business context you own, and it is protected by one session cookie that usually never expires.
So the lesson is not "AI is dangerous". The lesson is that AI sessions deserve the same treatment as an admin console, not the same treatment as a search box.
What we would do this week
- Treat AI chat sessions like privileged identities. Enforce re-authentication, shorten session lifetimes, and require SSO with device checks where the vendor supports it. If the session cookie can read the whole account, it should expire like an admin session, not like a favourite website.
- Kill automatic previews and unreviewed shares. Turn off auto-preview for shared content where the setting exists, and tell staff that an unexpected share link is a payload, not a courtesy.
- Log the API layer, not the screen. If your monitoring only sees browser activity, it is blind to this class of attack. Track authenticated calls from the AI product's own APIs, with volume and scope alerts.
- Minimise what the session can reach. Separate personal and business accounts. Keep client-confidential material out of general chats. Use projects or workspaces with tighter scoping when they exist, and delete what you no longer need.
- Audit your own integrations for the same four mistakes. Unchecked
postMessagelisteners,innerHTMLsinks, unsandboxed iframes, and CSP allowlists that are wider than the feature needs. This is a two-hour review that pays for itself the first time. - Review vendor share features before you enable them. Ask what a shared artefact can do in the viewer's session, not just what it displays.
The takeaway
The industry just watched a public share link become a code delivery mechanism into an authenticated AI session, and the vendor fixed it in eight days, which is genuinely fast work.
What remains is the design question every team building on AI now has to answer: how much context does this session hold, how long does it last, and what can run inside it?
At aratech we build the AI infrastructure our clients run on, and this is the exact seam we keep coming back to. Agents, copilots and chat assistants are not add-ons bolted onto your stack. They are identity-bearing components with access to your most valuable context. Treat the session like the asset it is, and a link that arrives in a support ticket becomes an annoyance instead of an incident.
If you want a second pair of eyes on where your AI sessions can reach, that is the conversation we like having.