ChatGPT share-link flaw let attackers run code in victims' sessions and read private chats; OpenAI has fixed it

A security firm called Parameter showed that a booby-trapped ChatGPT share link could run the attacker's code inside the signed-in session of anyone who opened it, and read that person's private conversations. OpenAI fixed the problem on October 26, 2026, and there is no patch for users to install. The practical lesson for IT teams is about how you treat shared AI links and what data people keep in their chat history.

What happened, in plain English

ChatGPT lets you share a conversation through a public link. Some shared chats contain interactive extras, such as a live graph or a "Preview" pane that shows HTML (the code behind web pages). The Preview runs inside a sandbox: a fenced-off box in the page that is meant to stop its contents from touching the rest of ChatGPT.

Researchers at Parameter found that the fence had a gap. It was not in the sandbox itself. It was in a helper component next to it. The interactive graph loads an open-source math-input library called MathLive. MathLive listens for messages from other parts of the page, but it did not check who sent them. Code in the sandboxed Preview could therefore send MathLive a message containing new web content, and MathLive placed that content into the main ChatGPT page.

From there, the injected content behaved as if it were part of chatgpt.com. ChatGPT has a Content Security Policy (CSP), a rule list telling the browser which code it may run. That policy allowed scripts from YouTube, and the researchers used a YouTube feature to supply the code that finally ran.

The result: a victim who was logged in to ChatGPT and opened the shared chat could have their recent conversation list and the contents of a private chat read and sent elsewhere. In the researchers' most reliable test, the victim only had to open the link and click Preview once.

Think of an office with a secure mail room. Packages are X-rayed and opened behind glass. The weak point was a clerk next to the glass who passed along any note slipped under the door, without asking who wrote it.

Are you affected? What to do now

Most readers have nothing to patch. ChatGPT's web app is run by OpenAI, and the fix was deployed on OpenAI's side.

Who was exposed:

• People who used ChatGPT in a web browser while signed in, and who opened a malicious share link before the fix. The researchers say they reported the issue on October 18, 2026, that partial protections were in place from October 22–23, and that OpenAI completed the fix on October 26, 2026.
• The researchers describe the issue as reachable across separate accounts and workspaces through public share links.

What is not known:

• Neither the researchers nor OpenAI have said publicly whether anyone exploited this before the fix. As of November 5, 2026, we found no public statement from OpenAI beyond what the researchers report. Treat exploitation status as unknown, not as "none".

Practical checklist for IT and security teams:

• No software update is required. Do not let anyone push a fake "ChatGPT security update" on you. Scammers often follow headlines like this one.
• Treat shared AI chat links like any other link from outside. Shared conversations from ChatGPT, and from similar assistants, can contain active content. Add this to awareness training next to "don't open unexpected attachments".
• Review what lives in chat history. The impact here was reading private conversations. If your organization uses ChatGPT, check your data-handling policy on pasting credentials, customer data or source code into chats, and use your plan's retention and history settings where available.
• If you are worried about a specific account, review its recent conversations and connected apps. Rotating a ChatGPT session is low-cost: sign out of all sessions from the account security settings and sign back in.
• If you build web apps that embed AI previews, widgets or third-party libraries, read the expert section below. The same class of bug can exist in your own product.

No indicators of compromise (IOCs) have been published by OpenAI or the researchers.

The expert view

Root cause. This is a classic cross-window messaging bug in a modern setting. The browser's postMessage mechanism lets frames on a page talk to each other. Safe use requires the receiver to verify both the sender's origin and the specific window that sent the message. MathLive's listener ran in the top-level chatgpt.com document and checked neither. It also accepted raw HTML as part of a configuration message (a keyboard layout) and inserted it without real sanitization.

The chain, conceptually. Each step was a reasonable feature on its own:

1. A shared chat that renders user-influenced content in a sandboxed Preview frame. The sandbox held.
2. An interactive graph in the same chat that pulls a third-party library into the trusted parent page.
3. That library's unauthenticated message listener, which turned "a message from the sandbox" into "HTML in the parent page".
4. Injected HTML that created a new, non-sandboxed frame, which inherited the chatgpt.com origin.
5. A CSP that blocked inline scripts but allowed an external host whose callback-style endpoint could be made to deliver executable script.

Once script runs with the chatgpt.com origin, it can call the same signed-in APIs the frontend uses. The researchers demonstrated listing conversations and reading a private one. They describe this as effectively account takeover, but they did not demonstrate changing account settings. That claim is plausible for same-origin script execution, but it was not shown.

Why the defenses failed. The sandbox was sound. The bridge around it was not. The researchers put it well: "Isolation is only as strong as every bridge across it." The CSP was a real control, but allowlisting a large third-party domain that offers callback (JSONP-style) endpoints is a well-known weakness. As the researchers note, a CSP "cannot make an unsafe rendering path safe."

Severity in context. There is no CVE and no CVSS score, which is normal for a server-side SaaS fix. OpenAI rated it P1 on its bug bounty scale after first triaging it as P2, according to the researchers. Reported reward: $5,000. The impact was real: one click, cross-account, and access to private conversation content on a service with a very large user base. Some limits make it less of a worst case than "account takeover by link" suggests. The victim had to be signed in and to open the link, and in the most stable variant to click Preview. The chain also depended on a timing race that the researchers handled with retries. We'd call it high impact, correctly fixed fast (eight days from report to full resolution), and not something that needs end-user action.

The broader trend. AI assistants are becoming rich, interactive web apps: previews, artifacts, canvases, plug-in renderers and third-party widgets inside a trusted origin. Each new renderer adds a trust boundary, and each library pulled into the parent page adds attack surface. Expect more bugs at the seams between "sandboxed output" and "trusted UI". For teams building similar products, the takeaways are concrete: verify event.origin and event.source on every state-changing message, never carry raw HTML in configuration data, keep dynamically created frames sandboxed, and treat CSP allowlists of big multi-purpose domains as a liability.

Still unknown. Whether the bug was exploited before October 26. Whether OpenAI's logs could detect exploitation. Whether other products that embed MathLive with similar trust assumptions are affected. Whether the MathLive project has changed its listener. As of November 5, 2026, we had not found a MathLive advisory.

Official sources

• Parameter Labs, "Do the Math: How We Took Over ChatGPT Accounts" (October 28, 2026)
• OpenAI bug bounty program (Bugcrowd)
• Coverage: The Hacker News, "A Shared ChatGPT Link Could Run Attacker Code in Your Session and Read Private Chats" (October 31, 2026)