One Click Into Someone Else’s ChatGPT: Cross-Frame Messaging Flaws

Key Takeaways

Researchers at Parameter disclosed on October 28, 2026 that a publicly shared ChatGPT conversation could run attacker-supplied JavaScript in the signed-in session of anyone who opened it, allowing the attacker to list the victim’s conversations, read a private chat that had never been shared, and send data to an external server [1][2]. OpenAI reproduced the issue, raised its severity from P2 to P1, and confirmed a fix across two versions of its web frontend on October 26, 2026, eight days after the report; users do not need to take any action [1][2]. According to The Hacker News, Parameter reports no real-world exploitation, and OpenAI has not publicly commented on exploitation [2].

The sandbox held, but the page around it did not. ChatGPT’s HTML Preview ran in an isolated, separate-origin frame as designed. The escape came instead through a third-party math-input library (MathLive) loaded into the main chatgpt.com page, whose cross-frame message listener accepted instructions from any sender and wrote attacker HTML into the trusted page [1]. Delivery required only a link: in the most reliable version the victim clicked Preview once, and Parameter later made Preview open automatically, so that opening the shared link was the only required action [1].

The root cause is a pattern rather than a one-off. Unvalidated postMessage listeners, unsanitized HTML sinks, unsandboxed srcdoc frames, and permissive Content Security Policy (CSP) allowlists are long-documented web weaknesses [6][7][8], and AI chat platforms are prone to combining all four because they render rich, user-generated content beside an authenticated session. Bearer tokens in the DOM then turned script execution into authenticated account access. Once script ran on the chatgpt.com origin, it read the session access token from a bootstrap element and called ChatGPT’s authenticated APIs directly; in the proof of concept this access was used to read private conversations, and the researchers assess that broader account actions would also have been possible [1][3]. Organizations building AI chat or agent interfaces should therefore audit every message listener and every component that renders model or user content, treating shareable conversations as untrusted input delivered with the platform’s own brand attached.

Background

Shared Conversations as a Delivery Channel

ChatGPT, like most major AI assistants, lets users publish a conversation through a public share link that anyone can open. Those links are routinely pasted into email, team chat, support tickets, and social media, and recipients are unlikely to treat a chatgpt.com URL with the suspicion they might apply to an unfamiliar domain [2]. From a defender’s perspective, that convenience creates a delivery channel in which attacker-authored content arrives on a trusted first-party domain, rendered by the platform’s own frontend, inside the recipient’s authenticated session. The Hacker News noted that the victim did not need to install anything, join a workspace, or sign in through the attacker [2].

ChatGPT has drawn sustained security research attention in 2026, and link-based delivery has appeared more than once. In July, Zenity Labs disclosed “AgentForger,” in which a crafted ChatGPT link auto-submitted a malicious prompt into Agent Builder and could create a rogue workspace agent holding the victim’s connected-app access; OpenAI had fixed that issue as of June 8, 2026, ahead of the coordinated public disclosure [10]. In September, Check Point Research described a covert cross-account channel through ChatGPT’s code-execution containers, which could be triggered when a victim opened a shared ChatGPT conversation and sent a normal message, among other delivery methods; the channel was closed when an internal artifact repository was decommissioned [9]. Content-rendering bugs in ChatGPT’s frontend are not new either, since Imperva documented cross-site scripting vulnerabilities in ChatGPT in 2024 [11]. Taken together, these reports suggest that AI chat frontends are now a well-studied target and that links into them deserve the same scrutiny as links into any other privileged SaaS application.

Preview Sandboxes and Rich Content

ChatGPT can render a block of HTML from a conversation as a small live web page through a feature called Preview. Because that HTML may contain arbitrary code, ChatGPT renders it in a restricted frame hosted on a separate origin, which under the browser’s same-origin policy cannot read or modify the parent chatgpt.com page [1][2]. Parameter’s write-up is explicit that this boundary worked: “The Preview sandbox itself worked” [1]. The vulnerability lay elsewhere, in a channel that legitimately crosses frame boundaries.

That channel is window.postMessage, the browser API that allows windows and frames on different origins to exchange messages. The API is safe only if the receiving code validates the sender. Mozilla’s documentation states plainly that any window can send a message to any other window, and that a receiver that does not check the origin and, where appropriate, the source of incoming messages exposes itself to cross-site scripting [6]. OWASP’s HTML5 Security Cheat Sheet gives the same advice and adds that message data should never be evaluated or inserted into the DOM as HTML [8].

Security Analysis

The Exploit Chain

Parameter’s attack combined a legitimate ChatGPT feature with weaknesses in a third-party component and two browser-level design choices. A shared conversation contained an interactive graph, which caused the main chatgpt.com page to load the MathLive library, an open-source web component for mathematical input. MathLive installs a message listener on the host page to coordinate with its virtual keyboard. Parameter reports that this listener’s origin policy was set to accept any origin and that it did not verify the sending window [1]. The current upstream MathLive source documents "none" as the default value of its originValidator option, with "same-origin" or a custom function available as stricter alternatives [4]. Parameter’s account does not state whether ChatGPT’s deployment relied on the default or set the option explicitly, but the upstream default suggests that integrators who do not override it inherit a listener that accepts messages from any origin.

From inside the Preview frame, the attacker’s HTML sent two messages to the parent page: one replacing a virtual-keyboard layout with attacker-supplied markup, and one telling the keyboard to display [1][3]. When the keyboard opened, MathLive assigned that markup to innerHTML on the main page through a createHTML helper that Parameter describes as an identity or Trusted Types wrapper rather than a sanitizer [1]. <script> elements inserted via innerHTML do not execute, and ChatGPT’s CSP blocked inline script, but the markup contained an <iframe srcdoc> element without a sandbox attribute. Such a frame parses a fresh document and, because the main page created it, inherits the chatgpt.com origin [1][7].

ChatGPT’s CSP blocked inline scripts but allowed scripts from YouTube. Parameter found that a YouTube oEmbed endpoint reflected a JSONP callback parameter into its response before returning a validation error, so loading that URL as a script executed attacker-chosen JavaScript inside the same-origin frame [1]. Parameter characterizes this step as “the final workaround for CSP, not the root cause” [1]. The script then read the session access token and account ID from a bootstrap element on the parent page and used them to call ChatGPT’s authenticated conversation APIs [1][3]. The table below summarizes each stage of the chain, the weakness involved, and the capability it handed to the attacker.

From One Click to No Clicks

Parameter documented two delivery variants. In the most stable reproduction, the victim opened the share and clicked the normal Preview button once [1]. The researchers then marked the HTML block as previewable so that ChatGPT opened it automatically; in that version, “Opening the shared link was the only required action,” and the payload fired after roughly 4.5 seconds across three reproductions in a separate account, including after a hard refresh [1]. A retry loop handled a race condition in which the payload’s messages arrived before MathLive finished loading [1]. Coverage has described the issue both as one-click and as effectively zero-click [2][3]; both characterizations are consistent with Parameter’s account, which treats the single-click version as the more reliable one [1].

Impact

The demonstrated impact was confidentiality loss in the victim’s account. The proof of concept enumerated recent conversations, retrieved a private conversation the attacker had never been granted, and sent a selected value to a researcher-controlled server through an image request [1]. The researchers state that the same JavaScript context could reach any action exposed by the frontend’s authenticated APIs: “Essentially, we could perform any action on behalf of the victim’s ChatGPT account” [2]. That claim is an inference from the access obtained rather than a demonstrated set of actions, since the proof of concept deliberately limited what it exfiltrated [1].

For enterprises the exposure extends beyond chat history. ChatGPT accounts increasingly hold uploaded documents, memory, custom GPTs, connector authorizations, and workspace agents, and earlier 2026 research showed how link-delivered attacks against those features can reach connected business applications [9][10]. CSA has not seen evidence that this chain was used to reach connectors, and Parameter did not demonstrate it, but security teams should assume that a full session compromise of an AI assistant carries the combined sensitivity of everything the assistant can see and do.

Why This Pattern Will Recur

The vulnerability class is not specific to OpenAI or to MathLive. AI chat interfaces render an unusual volume of untrusted rich content, including model-generated code, interactive charts, math notation, diagrams, and live HTML previews, and they typically do so by loading specialized third-party libraries into the main authenticated page. Each such library may bring its own message listeners and DOM sinks that were designed for embedding scenarios rather than adversarial ones. MathLive itself received a separate advisory in 2026, CVE-2026-54705, for unescaped text in \text{} and \mbox{} commands leading to cross-site scripting, fixed in version 0.110.0 [5]. That issue is distinct from the cross-frame message path Parameter used, but it reinforces that rendering components carry their own attack surface.

CSA’s analysis of the WriteOut flaw in Writer’s agent preview feature earlier this year described a similar architectural lesson: a preview mechanism meant to isolate untrusted content became the path to session theft because the boundary around it was weaker than the sandbox inside it [12]. In both cases, the isolation primitive worked as designed while an adjacent trust decision undermined it. Defensive reviews that test the sandbox but not the channels into and out of it are likely to miss this class of flaw.

The final link in the chain, a readable bearer token in the page, is also common. Single-page applications often bootstrap session data into the DOM or JavaScript memory for API calls. Same-origin script already has substantial access to a live session even without a readable token, but where the token is exposed, any same-origin script execution can also extract a reusable credential, which raises the stakes of every XSS-class defect on the origin.

Recommendations

Immediate Actions

No end-user action is required for this specific issue, since OpenAI’s fix was deployed server-side [2]. Security teams should nonetheless use the disclosure to brief users that shared AI conversation links are attacker-controllable content, even when they carry a trusted domain, and should handle unsolicited share links with the same caution applied to unsolicited document-sharing links.

Teams that build web applications should also run a quick inventory of message event handlers in their own frontends and bundled dependencies. The independent Dev.to analysis of this chain recommends flagging any addEventListener('message', ...) or onmessage handler that never references event.origin or event.source, with higher priority where the handler reaches a DOM sink such as innerHTML, and then confirming findings at runtime by sending synthetic messages from a foreign origin [3]. Static matching of this kind is heuristic and will not prove the absence of a flaw, but it locates the highest-risk code quickly. Any application that embeds MathLive should explicitly set originValidator to "same-origin" or a strict allowlist function rather than relying on the documented default of "none" [4], and should upgrade to version 0.110.0 or later to address CVE-2026-54705 [5].

Short-Term Mitigations

The four root-cause weaknesses in this chain each have a well-established control, and applying all of them provides layered defense. The measures in the table below, drawn from the researchers’ recommendations and standard browser-security guidance, should be applied to any frontend that renders untrusted content beside an authenticated session [1][3][6][7][8]. Each control maps to a specific stage of the exploit chain described earlier, so a team can confirm that no stage remains unaddressed.

The last of these controls deserves a qualification. Keeping tokens out of the DOM limits persistence and replay outside the victim’s browser, but it does not stop injected script from making authenticated requests within the live session. It therefore complements rather than replaces the preceding controls, which are what prevent attacker script from reaching the authenticated origin in the first place.

Strategic Considerations

Platforms that build AI chat and agent interfaces should treat rich-content renderers as part of their trusted computing base. Third-party libraries loaded into the main authenticated origin warrant a security review proportionate to the session they share, including an inventory of the listeners and sinks they install. Where feasible, renderers for untrusted content should be moved entirely into separate-origin frames, with a narrow, schema-validated messaging interface to the parent, so that a defect in a math, chart, or diagram library cannot reach the session.

Enterprises that consume these platforms should factor shared-link and preview features into vendor risk assessments. Useful questions include whether shared conversations can execute content automatically on open, whether administrators can disable public sharing or preview, what session tokens are exposed to frontend script, and how the vendor tests third-party frontend components. OpenAI’s eight-day remediation and P1 rating in this case are a positive signal about response, but they do not substitute for understanding how a platform’s architecture limits the blast radius of the next frontend flaw [1][2]. Organizations should also log and review connector authorizations and agent creation events in AI workspaces since, as the AgentForger research illustrated, those are natural targets for an attacker seeking persistence after hijacking a session [10].

CSA Resource Alignment

CSA’s research note WriteOut: Session Isolation Flaw in Writer AI Previews is the closest prior analysis of this vulnerability class [12]. It examined a one-click, cross-tenant account takeover in which an AI agent preview feature exposed the victim’s session to attacker-controlled code, and it identified preview-and-session exposure as a recurring pattern across AI agent platforms. The ChatGPT share-link chain fits that pattern closely while arriving by a different route: rather than a session cookie being forwarded into the sandbox, attacker code escaped the sandbox’s neighborhood through a cross-frame message channel. Readers should treat the two notes together as evidence that preview features in AI platforms require boundary testing that extends beyond the sandbox itself.

The SaaS Security Capability Framework (SSCF) provides customer-facing security capabilities that SaaS providers should expose, with identity and access management as its largest domain [13]. Several SSCF capabilities apply directly to the enterprise questions raised here, including administrative control over sharing features, session management, and the logging needed to detect anomalous API use from a hijacked session. Enterprises can use SSCF as a structured basis for asking AI platform vendors how sharing and preview features are governed.

The AI Controls Matrix (AICM) v1.1 offers the control baseline for organizations building or operating AI applications [14]. Its Application and Interface Security (AIS) domain covers secure development and testing of application interfaces and can be applied to validation of cross-frame messaging and output encoding in AI frontends. Its Threat and Vulnerability Management (TVM) domain addresses tracking and remediating vulnerabilities in third-party components such as MathLive, and its Identity and Access Management (IAM) domain addresses protection of session credentials. Mapping the four root-cause weaknesses in this chain to those domains gives development teams a way to fold the lessons from this disclosure into existing control assessments.

References

[1] Goyal, Mukul (Parameter). “Do the Math: How We Took Over ChatGPT Accounts.” Parameter Labs, October 28, 2026.

[2] Khandelwal, Swati. “A Shared ChatGPT Link Could Run Attacker Code in Your Session and Read Private Chats.” The Hacker News, October 31, 2026.

[3] Labbe, Sam. “We Took Over ChatGPT Accounts: The MathLive postMessage Chain, and the 20-Line Audit for Your Own Listeners.” DEV Community, October 31, 2026.

[4] MathLive Project. “src/public/options.ts — OriginValidator option and default.” GitHub, accessed October 31, 2026.

[5] GitLab Advisory Database. “CVE-2026-54705: MathLive Lack of Escaping of HTML Allows for XSS.” GitLab, July 29, 2026.

[6] Mozilla Developer Network. “Window: postMessage() method.” MDN Web Docs, accessed October 31, 2026.

[7] Mozilla Developer Network. “\<iframe>: The Inline Frame element.” MDN Web Docs, accessed October 31, 2026.

[8] OWASP. “HTML5 Security Cheat Sheet.” OWASP Cheat Sheet Series, accessed October 31, 2026.

[9] Check Point Research. “The Shared Clipboard Inside the Sandbox: Cross-Account Data Leakage in ChatGPT.” Check Point Research, September 8, 2026.

[10] Lakshmanan, Ravie. “ChatGPT AgentForger Flaw Could Deploy Rogue Workspace Agents via a Phishing Link.” The Hacker News, July 24, 2026.

[11] Masas, Ron (Imperva). “XSS Marks the Spot: Digging Up Vulnerabilities in ChatGPT.” Imperva Blog, February 2024.

[12] Cloud Security Alliance. “WriteOut: Session Isolation Flaw in Writer AI Previews.” CSA AI Safety Initiative, July 8, 2026.

[13] Cloud Security Alliance. “SaaS Security Capability Framework (SSCF).” Cloud Security Alliance, September 2025.

[14] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, June 2026.