What happened
In a post titled “How We Took Over ChatGPT Accounts,” Parameter Labs describe an exploit in ChatGPT’s implementation of interactive HTML previews, an iteration of the artifacts feature previously called Canvas. The previews render custom HTML applications in a sandboxed iframe. The purpose of that isolation is to prevent untrusted code from interacting with OpenAI APIs or accessing private user data.
The reported chain crossed that boundary through MathLive, a JavaScript library OpenAI uses for graph support. MathLive includes a virtual keyboard that can be triggered in the parent page with postMessage(). According to the account, the message-receiving code used innerHTML, and there was no mechanism to stop other sandboxed frames—including HTML preview frames—from calling it. Untrusted frame content could therefore inject HTML into the parent page. While innerHTML does not itself execute script elements, the injected markup could create an iframe without sandbox restrictions.
The next step worked around the page’s Content Security Policy (CSP). Parameter Labs say OpenAI’s policy blocked inline scripts and allowed scripts only from a limited set of domains. YouTube was among the permitted sources; its oEmbed endpoint could be used to reflect JavaScript in a way that executed it. With JavaScript running on ChatGPT, the researchers say it was straightforward to fetch private user data from APIs and exfiltrate it through an image reference.
The practical delivery mechanism was a ChatGPT share URL. A recipient who opened the URL while signed in could have private data exfiltrated or actions taken on their behalf. The source says OpenAI closed the vulnerability and paid a $5,000 bug bounty. It does not give a disclosure or patch date beyond the publication date implied by the source URL, nor does it specify affected versions, the number of exposed accounts, or whether any real user was targeted.
The chain matters because each individual control described in the account had a limited, plausible role. The preview was sandboxed. Inline scripts were blocked. Script sources were restricted. Yet cross-frame messaging let a sandboxed document influence parent-page markup, and a permitted external origin supplied the final execution path. The exploit was therefore not a claim that iframe sandboxing is useless; it was a failure of the surrounding integration to preserve that boundary.
What the archive adds
This is a new fact on a known ChatGPT account-security story. A prior Field Note covered a newly fixed P1 chain that could take over accounts through a shared conversation link; the current source supplies a technical account of an HTML-preview route, including the MathLive message handler and CSP bypass. The archive also has coverage of ChatGPT account switching, but that is not evidence of a connection to this vulnerability.
Trend signal
This incident supports agent security moves to runtime boundaries: the exploit depended on interactions among a sandboxed frame, parent-page message handling, injected markup, and host CSP rules. A frame’s nominal sandbox is not a complete security boundary if host-page capabilities can be reached through another component.
Why now
The source reports that OpenAI has already closed the hole, so this is not a call for users to avoid ChatGPT share links or an assertion of an active attack. Its immediate value is architectural: HTML previews and other generated interactive artifacts are becoming normal application surfaces. Teams adding them now can use this disclosure to review the boundaries before feature design hardens around unsafe message or embedding assumptions.
Why it matters
Teams building AI products often render user-supplied or model-generated content inside an otherwise trusted application. This case is a reminder that sandboxing cannot be evaluated in isolation: message handlers, third-party libraries, permitted script origins, and the browser’s treatment of newly created frames all become part of the boundary. A policy that blocks inline scripts may still be insufficient if a trusted origin can reflect executable content.
The account also illustrates how a seemingly narrow UI feature can create access to the authenticated application. A shared link is convenient, but opening it while signed in can carry consequences if preview content crosses into the parent context. Product and security teams should threat-model the complete path from shared artifact to host APIs, and test whether untrusted content can create unsandboxed execution or trigger privileged actions. The source does not establish that this chain was exploited against users, so the lesson is preventive rather than evidence of a confirmed breach.
What happens next
- More teams will audit preview and artifact surfaces as host-application security boundaries (6 months, 65%). Watch for: product security guidance or engineering changes that restrict cross-frame messages, embedded origins, or artifact capabilities.
- The practical review unit will shift from an iframe configuration to an end-to-end capability path (12 months, 70%). Watch for: tests that trace a preview’s messages, created frames, network permissions, and routes to authenticated APIs.
Limits and uncertainty
The supplied account describes the researchers’ exploit chain and says OpenAI closed the hole, but does not identify the affected software versions, the dates of discovery, disclosure, or remediation, or the conditions under which a recipient would be exposed. It gives no evidence that attackers used the issue against real accounts, how many users may have been at risk, or what data or actions were actually accessed. The $5,000 bounty figure is reported, but the source does not provide OpenAI’s response or explain the award’s basis.
The account also does not establish whether the relevant MathLive behavior, CSP configuration, or HTML-preview implementation remains available in any changed form after the fix. The forecasts above are architectural expectations, not claims about OpenAI’s planned product or security work.
Skill to build now
Run a focused boundary review for any feature that renders generated or user-provided HTML. Inventory every postMessage() receiver, require explicit origin and sender validation, and identify whether accepted data reaches HTML injection or privileged application actions. Then test whether embedded content can create a less-restricted child frame or load executable content through an allowlisted origin. Record the expected permissions for the preview separately from those of the signed-in host.
Reader takeaway
A sandbox is only as strong as the code that connects it to the host page. When your product renders untrusted HTML, audit the full chain—cross-frame messaging, libraries, CSP allowlists, and any route to authenticated APIs—rather than treating the iframe attribute as the security review.
Open question
What specific boundary change did OpenAI deploy, and does it address the complete class of cross-frame message and allowlisted-origin interactions described in the report?