Before OpenAI fixed it on Oct. 26, a normal-looking ChatGPT public share link could execute attacker-controlled code inside the signed-in viewer’s chatgpt.com session and read private-chat data in a controlled test, according to a technical report published Oct. 28 by Parameter. The finding matters because it did not depend on cracking the HTML Preview sandbox itself. It emerged from the way public sharing, a trusted graph component and the authenticated host page interacted.
For business users and security teams, the pressing question is not whether every viewer was compromised. Nothing in the available reporting shows that, and no source in this packet reports real-world exploitation. The harder question is whether AI assistants are being assessed as full browser applications, where untrusted content, third-party libraries and privileged sessions can quietly collapse into the same attack surface.
The sandbox held; the bridge did not
Parameter said the most reliable early version required a victim to click Preview once; by Oct. 17 it had a version that opened the Preview automatically, leaving link-open as the only required action. In the demonstrated chain, a malicious shared conversation combined an interactive graph with an HTML Preview. The Preview ran on a separate origin and, on its own, could not read the main ChatGPT page. The break came through MathLive, a library loaded by the graph.
According to Parameter, MathLive installed a postMessage listener in the main page for virtual-keyboard settings but did not adequately verify both the sender origin and the sender window. It also accepted raw HTML as keyboard-layout data. That gave attacker-influenced content a route into the privileged page. From there, the chain created a new iframe from attacker-controlled markup without a sandbox attribute. Because the frame inherited the chatgpt.com origin, code running inside it could act like code from the signed-in site itself.
ChatGPT’s content security policy still blocked inline scripts, so this was not a one-step shortcut. Parameter said it used a YouTube oEmbed JSONP behavior as the final path to script execution. Once same-origin JavaScript was running, it could call authenticated frontend APIs. In Parameter’s controlled proof, the code enumerated recent conversations, fetched a private conversation that had never been shared with the attacker, and sent only a small selected value to an external server.
Why this matters beyond ChatGPT
That sequence is why the incident carries more weight than a routine web bug. Each individual piece sounds bounded: a public share page, a sandboxed preview, an interactive graph, a third-party message listener, a frame created on the fly, a content-security policy. The problem appeared at the seams. As a research note from the Cloud Security Alliance put it, the Preview sandbox did what it was supposed to do; the host page trusted a cross-frame message and then created a new privileged document from attacker-controlled markup.
For vendors building AI assistants, that is a warning about product architecture, not just code hygiene. Rich model outputs now live inside authenticated pages that may also expose conversation history, workspace information, uploaded content or connected services. This particular research did not demonstrate access to those broader categories, and the reporting does not identify which account or workspace types were affected. But it shows how quickly a feature that looks like rendering can become a session problem when the browser is asked to mix trusted and untrusted content.
What to do with the lesson
Parameter says it confirmed the production path on Oct. 13, reported it through OpenAI’s bug-bounty program on Oct. 18, added the private-chat proof on Oct. 19, and received notice of remediation on Oct. 26. It also says OpenAI reproduced the JavaScript execution and private-chat access, upgraded the issue from P2 to P1 on Oct. 21, completed fixes across two web frontends on Oct. 26, and paid a total $5,000 bounty. The Hacker News later independently summarized the disclosure and likewise reported no known in-the-wild use.
OpenAI’s exact remediation is not public in the supplied sources, and no standalone public advisory is included here. Even so, the design lessons are unusually concrete. Product teams should treat public share links as attacker-controlled input even when they render on first-party pages. Cross-frame commands need to verify both `event.origin` and `event.source`. Configuration messages should carry structured data, not raw HTML. Any document created from untrusted content needs its own sandbox rules, not just the parent’s. Where possible, session-critical material should be kept out of easily readable page bootstrap data. And content-security policy should be treated as a backstop, not as permission to relax earlier trust checks.
Security teams can translate that into test plans. Browser applications should be reviewed across features, not just component by component. Public links, live previews, embedders, third-party libraries and authenticated APIs need to be exercised together. Monitoring can help too: an unusual burst of conversation-list or conversation-read API calls immediately after a shared page loads is the kind of cross-feature signal conventional app reviews may miss.
For users, the practical takeaway is narrower than the headline. The research describes a fixed flaw, demonstrated between test accounts, with no reported evidence of outside victims in the materials here. Nothing in the reporting suggests a general need to reset passwords. The more useful response is procurement and governance pressure: ask whether an AI product that renders interactive content inside a logged-in browser session is tested like a modern web app, because that is what it has become.
By
By
By
By
By
By
