Parameter report to OpenAI October 18, 2026; fix completed October 26, 2026; write-up October 28, 2026
A Shared ChatGPT Link Could Run Code in Your Session and Read Private Chats: OpenAI Fixes a P1 Flaw
Researchers at Parameter showed that an ordinary ChatGPT share link could run attacker code inside the signed-in session of anyone who opened it, with the same access as the real ChatGPT site. In their controlled test, the code listed the victim recent conversations, opened a private conversation that had never been shared with the attacker, and sent a portion of it to a researcher-controlled server, calling ChatGPT own signed-in APIs directly. Parameter reported no real-world use of the flaw, and ran the proof between separate researcher accounts. The chain is instructive because the obvious defense held: ChatGPT renders HTML from a chat through its Preview feature inside a sandboxed frame on a separate address, and that sandbox was not broken. The way in was a second feature in the same shared conversation, an interactive graph that loaded the MathLive math library into the main ChatGPT page. That library left a message listener that accepted keyboard messages from any sender, with no origin check, and allowed the message to carry raw HTML that was inserted without real sanitization. The injected HTML created a new frame with no sandbox that the browser treated as part of chatgpt.com, and a script loaded from YouTube, which the content security policy allowed, supplied the final code. Parameter reported the flaw through the bug bounty program on October 18; OpenAI reproduced both proofs, raised the severity from P2 to P1, its most serious category, fixed both affected frontend versions by October 26 so they reject the messages the attack relied on, and paid a 5,000 dollar bounty. The fix is server-side, so users have nothing to install or reset.
Executives
The business lesson is about shared links as an attack surface: a link that looks like a helpful shared conversation carried code that acted as the person who opened it. No password was stolen and no account was breached in the classic sense; the session itself was borrowed. For any AI tool your staff open links into while signed in, the vendor session isolation and message handling are security properties worth a line in your vendor record, alongside the data questions you already ask.
CIO / CISO
No action is required on the fixed flaw itself, and that should be stated plainly so teams do not invent work. The transferable control is architectural: any product that renders shared or generated HTML near an authenticated session should be asked how frames communicate, whether message senders are origin-checked, and whether user content can ever reach the trusted page as raw HTML. Parameter own summary is the checklist: a content security policy is defense in depth, and it cannot make an unsafe rendering path safe. Record the October 26 fix date in the ChatGPT vendor entry and move on.
Engineers
Review your own postMessage handlers with this chain open beside you: verify the sender origin on every listener, never pass message data into innerHTML, and never let content from a sandboxed frame create an unsandboxed frame that inherits your origin. The failure here was a library loaded for an unrelated feature, a math keyboard, leaving a permissive listener in the main page, so audit listeners contributed by third-party components, not only the ones your team wrote.
Everyone (non-IT)
You do not need to change any setting, and OpenAI has already fixed this on its side. The habit worth keeping is general: a shared chat link from a stranger deserves the same caution as any other unexpected link, even when it opens on a site you trust, because what runs after you open it is the part that matters.