ChatGPT Share-Link Flaw Fixed: Your Chats Were at Risk 2026

A link that looked like any other shared ChatGPT conversation could, until last week, have let a stranger read chats you never shared with them. Not by guessing your password, not by tricking you into installing anything — just by getting you to open a link.

That is the finding security firm Parameter published on 28 October 2026 in a write-up titled "Do the Math: How We Took Over ChatGPT Accounts." OpenAI fixed the flaw on 26 October, two days before the write-up appeared, and classified the report as P1. No evidence of real-world exploitation has been reported, and there is nothing users need to install. This article explains what happened, why it worked, and what — if anything — you should do about it.

What the researchers found

Parameter's team showed that an attacker could build an ordinary-looking public ChatGPT conversation, publish it with ChatGPT's normal sharing feature, and send the resulting chatgpt.com/share/ link to a victim. When a signed-in user opened that link, the attacker's code could run inside their ChatGPT session.

From there, the researchers demonstrated three things that turn a curiosity into a serious flaw:

• The code could list the victim's recent conversations.
• It could read the contents of a private conversation that had never been shared with the attacker.
• It could send data from that conversation to a server outside ChatGPT.

Because the code ran with the web application's own authenticated access, Parameter concluded it could essentially act on the victim's account — not just read one chat, but call ChatGPT's authenticated APIs as that user. That is why the report is described as an account takeover, even though the proof itself was limited to reading conversation data: the power came from where the code ran, not from any single action it performed.

One detail matters for how worried you should be. In the most stable version of the proof, the victim had to click ChatGPT's normal Preview button once. In a later version, the researchers marked the HTML block so ChatGPT opened it automatically, and the payload fired roughly 4.5 seconds after the link opened — reproduced three times in a separate account, including after a hard refresh. In other words, the polished version needed no click at all beyond opening the link.

How five harmless-looking features combined into one hole

The most useful lesson in this story is that no single feature was obviously broken. The flaw lived in the seams between features that each looked reasonable on its own.

HTML Preview is sandboxed — and that part worked. ChatGPT can turn an HTML code block into a small working page. Because that page can contain arbitrary code, ChatGPT runs it inside a restricted frame on a different web address, so it cannot directly read the main ChatGPT page around it. Parameter confirmed that isolation held: code inside the Preview could not simply reach into the signed-in page.

A graph quietly loaded a second component into the main page. The same conversation could also contain an ordinary interactive graph. Behind the scenes, the graph loaded a maths library called MathLive, which installed a listener in the main ChatGPT page for messages controlling its on-screen keyboard.

That listener trusted any sender. Browsers let frames exchange messages through a mechanism called postMessage — think of it as a mail slot between two pages that cannot otherwise read each other. A mail slot is safe only if the receiver checks who posted the message. MathLive's listener did not: it accepted messages from any web address, and it allowed a message to replace the virtual keyboard's layout with raw HTML, which the main page then rendered.

The rendered HTML could create an unsandboxed frame. Script tags inserted that way do not run on their own, so the researchers used an embedded frame carrying its own HTML. Because the main ChatGPT page created that frame without sandbox restrictions, the browser gave it the chatgpt.com identity — and code inside it could access the signed-in page.

A YouTube quirk got past the last guard. ChatGPT's Content Security Policy blocked inline scripts, but it allowed scripts from YouTube. YouTube's oEmbed endpoint reflected a crafted callback name back in its response before returning an error, and because YouTube was already an allowed script source, the browser ran it. Parameter is clear that this was a workaround, not the root cause: blocking that endpoint alone would have removed one path while leaving an untrusted Preview able to insert HTML into the main page.

The researchers' own summary of the defensive lessons is worth repeating, because it applies far beyond ChatGPT: a message receiver should verify both the sender's address and the exact window that was given permission; settings that cross between windows should never contain raw HTML; dynamically created documents should stay sandboxed when their content can be influenced by an untrusted frame; and a content security policy should be a backup control, not the only barrier once attacker-controlled HTML reaches the main site.

The timeline: reported 18 October, fixed 26 October

The dates below come from Parameter's write-up, which is the primary source for this story. OpenAI has not published its own advisory on this flaw as far as secondary coverage could find, so the severity rating and fix date are the researchers' account of their bug-bounty thread — and this article labels them as such throughout.

Eight days from report to fix is a fast turnaround for a flaw of this severity, and Parameter credits OpenAI with reproducing both the code execution and the private-conversation proof. The debate that followed was not about speed — it was about the price tag.

The $5,000 question

OpenAI paid a total bounty of $5,000 for a one-click, full-account-takeover chain. Security commentator Simon Willison, writing on 31 October, said the amount was "a bit cheap for a vulnerability this serious."

That is an opinion, and it should be read as one. But it points at a real tension in bug-bounty programmes: the payout signals to every other researcher how much a top-severity report is worth. If the price looks low for the most serious class of bug, the worry is that the next researcher might not bother reporting at all. Nothing in the write-up suggests Parameter was dissatisfied — the debate is about the incentive structure, not about this particular payment — but it is a fair question for OpenAI's programme to answer over time.

No CVE identifier has been assigned for this flaw, according to secondary summaries of the disclosure, which is consistent with a server-side web fix rather than a vulnerability in shipped software that users need to patch.

What you should actually do

The honest answer is: very little, and nothing urgent.

1. Nothing to install, update or reset. The fix lives on OpenAI's servers, across both versions of its web frontend. Opening a crafted share link today does not run the payload.
2. Only open share links from senders you trust. This was always good advice, and this story is the reason why. A chatgpt.com address in the link is not, on its own, proof that the conversation behind it is safe — the whole point of this flaw was that the danger arrived inside a genuine ChatGPT share.
3. Delete shared links you no longer need. In ChatGPT, go to Settings, then Data Controls, then Shared Links, and remove links for conversations you shared once and forgot. Fewer live public links means a smaller surface for any future sharing-related issue.
4. Treat every share as public. This is the part readers most often misunderstand, so it deserves its own section.

Do not confuse the bug with sharing itself

Since this story broke, social posts have also warned that sharing a ChatGPT conversation creates a public URL that Google can index. That warning is accurate — but it describes the feature working as designed, not this bug.

A shared conversation is public by design: anyone with the link can open it, and public share pages can appear in search results. The bug was something else entirely — a way for a crafted share to run code in the viewer's session and read chats the viewer had never shared. One is a privacy choice you make when you press Share; the other was a security hole that has now been closed.

The practical rule covers both: share only conversations you are comfortable with anyone reading, and open only shares from people you would trust with that same standard in reverse.

Why this story matters beyond ChatGPT

If you use ChatGPT mainly for writing help or brainstorming, this flaw probably feels distant — it is fixed, nobody is reported to have been hit, and your chats were almost certainly never near it. Its value is as a case study in how modern web applications fail.

Each piece of the chain was built by a different team, for a different purpose, and each one passed its own review. Preview needed sandboxing, and it had it. Graphs needed a maths keyboard, and MathLive provided one. Frames needed a way to talk to each other, and postMessage is the standard tool. Content policies needed trusted media sources, and YouTube is one. Sharing needed to be frictionless, and it was. The vulnerability appeared only when all of those reasonable decisions met on a single page — which is exactly the kind of failure that single-feature security testing misses.

That is also why the fix is worth noting precisely: OpenAI did not just block the YouTube endpoint or patch one frame. According to Parameter, both web frontends now reject the reported cross-frame messages — the seam itself was closed, not just the last step of the chain.

For readers, the takeaway is simpler and more durable than any single bug: the sender matters more than the domain. A link can be a genuine link to a genuine service and still carry something you should not open. Trust the person who sent it, not just the address bar — and keep your own shared links tidy, because everything you share is public from the moment you create it.

Recommended Reading

If this story has you thinking about how AI systems can go wrong in ways their builders did not foresee, Mustafa Suleyman's The Coming Wave is a useful companion read — it looks at the risks of powerful new technologies and what containing them might actually require. Read more on The Coming Wave at BookNest.

As an Amazon Associate, AI Trends Daily earns from qualifying purchases.

The featured image is an original AI-generated illustration, not a photograph. Sources: Parameter, "Do the Math: How We Took Over ChatGPT Accounts" (28 October 2026); The Hacker News, "A Shared ChatGPT Link Could Run Attacker Code in Your Session and Read Private Chats" (31 October 2026); Simon Willison on the disclosure (31 October 2026). Related reading on this blog: ChatGPT vs Gemini vs Claude in 2026, how to opt out of AI training on your content, and the PHP2Shell critical vulnerability explained.