One ChatGPT Link Could Have Read Your Private Conversations

Someone sends you a link to a shared ChatGPT conversation. You click it, glance at an interactive chart, and move on with your day. What you would never have seen: in about four seconds, code running inside that page listed your private conversations, opened one you never shared with anyone, and quietly sent data to a server across the internet. No password stolen. No login page faked. Your own signed-in session did the work.

That is not a hypothetical. It is a vulnerability that security researchers at Parameter demonstrated against ChatGPT this fall — and that OpenAI has since fixed. The details matter, because the chain behind it is a masterclass in how modern attacks are assembled from small, trusted pieces.

How one link became a skeleton key

The attack started with a shared conversation containing an interactive graph and ChatGPT’s HTML Preview feature. Preview is designed to run code safely, inside a restricted frame on a separate web address, so it cannot touch the main ChatGPT page. That wall held — at first.

The break came from an unlikely component: a math library called MathLive, which ChatGPT uses for a virtual keyboard. MathLive had added a message listener to the main page, and it accepted instructions sent through the browser’s postMessage interface without properly checking who sent them. The isolated Preview frame could talk to it. One message delivered a fake keyboard layout stuffed with attacker-controlled HTML. A second message opened the keyboard, and the layout was dropped straight into the real ChatGPT page through innerHTML, passing through a helper that never stripped the unsafe markup.

From there the chain kept climbing. The injected HTML planted a frame using srcdoc, a technique that embeds a page directly in an attribute. This frame carried no sandbox restrictions, so it inherited ChatGPT’s own web origin and could reach the parent page. ChatGPT’s Content Security Policy blocked inline scripts, but it allowed scripts from YouTube — and YouTube’s oEmbed endpoint would return an attacker-supplied callback as executable JavaScript. Loading that response was the final rung: code now running as chatgpt.com itself.

The payload then did exactly what a real attacker would want. It read the session details available to ChatGPT’s own frontend and called the same authenticated conversation APIs the app uses, retrieving a private conversation that had nothing to do with the shared link, then exfiltrated a sample value through a simple image request. In the final version of the proof of concept, the victim did not even need to click Preview — the trap sprang automatically, and the researchers reproduced it three times in a separate account, with execution starting after roughly 4.5 seconds.

Fixed fast — and worth understanding anyway

The good news is the responsible-disclosure system worked. Parameter reported the flaw on October 18. OpenAI reproduced it, raised it to P1 priority on October 21, and shipped a fix on October 26 so the frontend rejects the malicious messages. The report earned a $5,000 bounty. If you use ChatGPT today, this specific hole is closed, and there is nothing for you to patch.

But notice what was never involved: your password. The attackers did not need credentials, MFA codes, or a phishing page, because the live browser session — already authenticated, already trusted — was the prize. It is the same lesson identity teams keep relearning in Microsoft 365 and Entra environments: whoever controls the session controls the account.

What this teaches defenders

• Third-party components are attack surface. A math keyboard library became the bridge across a security boundary. Every widget embedded in a trusted page inherits that trust, whether it earned it or not — inventory and audit them like you would any other software supply chain.
• Cross-frame messages need bouncers. Any postMessage listener must verify both the sender’s origin and the exact source window before acting. Accepting instructions from “whoever knocks” is how sandboxes get escaped.
• Untrusted HTML must stay untrusted. Content rendered through innerHTML without sanitization, and srcdoc frames without sandbox flags, turn display features into execution features.
• A CSP is only as strong as its allowlist. Blocking inline scripts meant little when an allowed domain offered a JSONP endpoint willing to reflect arbitrary JavaScript. Old endpoints on trusted domains are load-bearing weaknesses.
• AI chats are data stores now. People paste code, contracts, and personal details into these tools. Treat shared-chat links with the same suspicion as any other link, sign out on shared machines, and think twice about what belongs in a conversation in the first place.

There is a temptation to file stories like this under “AI is insecure.” That misses the point. Nothing here was an AI failure — the model was never the target. This was classic web security: a message listener that trusted too much, HTML that was never sanitized, a sandbox quietly dropped, and an allowlist with a soft spot. The platform was new; the mistakes were the same ones the industry has been making for twenty years. The teams that internalize that — who treat their AI tools with the same rigor as any other business application — are the ones this story should reassure, not scare.

The research behind this story was disclosed by Parameter (technical write-up by Mukul Goyal), and the timeline and exploit details were reported by Cyber Security News — both worth reading for the full technical chain.