Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

A Shared ChatGPT Link Could Run Attacker Code and Read Private Chats

A now-patched chain of three web design flaws let a booby-trapped ChatGPT share link execute code in a victim's signed-in session and pull their private conversations. OpenAI fixed it within eight days; users don't need to do anything.

4T4Tify Team4Tify
Oct 31, 2026·5 min read
A Shared ChatGPT Link Could Run Attacker Code and Read Private Chats

A Shared ChatGPT Link Could Run Attacker Code and Read Private Chats

A single ChatGPT share link — the kind people paste into emails, support tickets and social posts every day — was enough to run an attacker's code inside the session of whoever opened it. From there, the code could list the victim's recent conversations, open a private chat that had never been shared, and send its contents to an outside server. OpenAI has fixed the issue, and ChatGPT users don't need to take any action.

What happened

The flaw was reported through OpenAI's bug bounty program on October 18 and fixed eight days later. OpenAI reproduced both the code execution and the private-chat access, raised the severity from P2 to P1 — its most serious category — and rolled the fix across two versions of the ChatGPT web front end. By October 26, both versions rejected the messages the attack depended on. A $5,000 bounty was paid.

The demonstration was a controlled test between separate accounts. There is no report of the technique being used against real users.

How the attack worked

The lure was an ordinary-looking shared conversation. The victim didn't have to install anything, sign in through the attacker or join a workspace. In the most reliable version, they opened the link and clicked ChatGPT's Preview button once; a later variant opened Preview automatically, so simply visiting the link was enough.

The exploit chained three design choices that, on their own, looked harmless:

  1. A sandboxed preview. ChatGPT can render a block of HTML from a chat as a small web page. That preview runs in an isolated frame on a separate web address, so it cannot read the main ChatGPT page. That sandbox held.
  2. A trusting library listener. The same shared chat contained an interactive graph, which loaded the MathLive math-input library into the main ChatGPT page. MathLive left a listener running for messages about its on-screen keyboard — and it didn't check which frame had sent them.
  3. HTML inside a "keyboard layout." Those messages were allowed to carry raw HTML as keyboard-layout data. So the isolated preview could send a message across the frame boundary and have its HTML inserted into the trusted main page.

That injected HTML created a new, non-sandboxed frame that the browser treated as part of chatgpt.com. The site's content security policy blocked inline scripts but allowed scripts served from YouTube, so the final payload was loaded from there. Once running with the victim's full web access, the code called ChatGPT's own signed-in APIs directly — meaning its reach went well beyond whatever happened to be on screen. In principle, it could act on the victim's behalf across the account.

The YouTube step was only a workaround for the content security policy, not the root cause. Blocking it alone would still have left an untrusted preview able to push HTML into the main site.

Why it matters

AI assistants increasingly hold sensitive material: source code, contracts, customer data, internal plans. A share link is a trusted, low-friction format, and this case shows how a feature built for convenience can become a delivery mechanism. It is also a textbook example of how a well-built sandbox can be undone by a third-party component on the other side of the wall: one cross-frame message handler without an origin check was enough to bridge the isolation.

What to do

  • ChatGPT users: nothing to install or reset — the fix is server-side. Stay cautious with shared chats from unknown senders and avoid clicking Preview on content you don't trust.
  • Organisations using AI assistants: treat chat histories as sensitive data. Set policy on what may be pasted into them and review which accounts and integrations have access.
  • Web and product teams: audit every postMessage listener in your own code and in bundled libraries. Validate the sender's origin, never accept raw HTML through a message channel, and treat any third-party script allowed by your content security policy as part of your attack surface.

Bugs like this live in the seams between components — a listener in one library, a policy exception in another. That's exactly the class of issue our AI-assisted code review is built to surface: it traces how untrusted input moves through your front end and bundled dependencies, flagging missing origin checks and unsafe HTML sinks before they ship.

SHARE