ChatGPT HTML Previews: What the Reported Account-Takeover Exploit Means

A sandboxed iframe in ChatGPT could reportedly reach into a signed-in user's account, execute JavaScript, fetch private data, and take actions on the user's behalf, according to Simon Willison's summary of an exploit described by Parameter Labs. ¹ For security and platform leaders, the question isn't whether a sandbox existed. It's whether anything inside it could reach the authenticated application around it.

The report describes an attack path, not evidence of mass compromise. It doesn't say how many users were affected or confirm that an attacker accessed real accounts or data. It describes the potential to access private user data and take actions, but does not specify the exact data or actions involved. ¹ That gap matters: the capability deserves scrutiny, but it doesn't establish the scale of any real-world impact.

What was the reported ChatGPT HTML previews vulnerability?

ChatGPT's interactive HTML feature, previously called Canvas, is described in Willison's post as now called HTML previews. ¹ Custom interactive apps were displayed in sandboxed iframes meant to stop untrusted code from interacting with OpenAI's APIs or accessing private user data. ¹

The problem wasn't that generated HTML could render. It was that code inside a sandboxed frame could influence the parent ChatGPT page. ¹ Analysis: that turns a rendering feature into an account-boundary problem. A sandbox only holds if content inside it can't use messages, browser quirks, or shared application features to reach outside the frame.

The lesson extends past ChatGPT. Content can be isolated one way and still have a route back through postMessage or other shared browser mechanisms. Analysis: teams should trace the full path from untrusted content to authenticated behavior. The presence of a sandbox tag is not proof of isolation.

How did the attack cross the iframe sandbox boundary?

ChatGPT used the MathLive JavaScript library to render graphs. MathLive's virtual keyboard could be triggered in the parent page by a postMessage sent from a sandboxed iframe. ¹

The parent's message handler processed that message with innerHTML and, according to the report, had no mechanism to prevent other sandboxed frames, including HTML preview frames, from calling it. Untrusted iframe code could therefore inject HTML into the parent page. ¹

innerHTML doesn't directly execute <script> tags, but the injected markup could create a new iframe without sandbox restrictions. ¹ Blocking one route to script execution didn't block the next one.

The final link was the page's content security policy, which blocked inline scripts and allowed scripts from a handful of domains, including YouTube. The report says YouTube's oEmbed endpoint could reflect JavaScript in a way that executed it. ¹

Analysis: several controls failed in sequence for this chain to work: an untrusted message was accepted by the parent, the handler inserted attacker-controlled markup, that markup spawned an unrestricted frame, and a permitted script domain provided an execution route. Auditing the HTML renderer alone, or the CSP alone, could miss how the pieces connected.

What did the account-takeover report actually demonstrate?

The chain reached JavaScript execution inside ChatGPT. The report says that code could fetch private user data from APIs and exfiltrate it through an image reference. ¹

The scenario involved a share URL: an attacker could create a ChatGPT share link, and when another signed-in user visited it, the exploit could access that user's data or take actions on their behalf. ¹

That describes capability, not confirmed impact. The report doesn't say how many people were affected or whether any real account or private data was accessed. It describes potential data access and account actions but doesn't specify which data or actions were involved. ¹

Analysis: a demonstrated path to code execution inside an authenticated app is a serious finding on its own, even without confirmed victims. Describing it as mass compromise would go beyond what the source supports. Incident write-ups should keep three things separate: exploit capability, observed access, and confirmed impact.

Did OpenAI fix it, and what's still unknown?

Willison's post says OpenAI closed the vulnerability and paid a $5,000 bug bounty. ¹ It gives no technical detail on the fix and no dates for discovery, reporting, or remediation. ¹

That leaves real questions open for anyone assessing similar exposure. Did the fix restrict which frames can send messages? Did it change how the parent handles inserted markup? Did it block unrestricted iframe creation, or tighten the CSP? The report answers none of these. ¹

Analysis: closure and a bounty payout indicate the issue was treated as a vulnerability, but they don't confirm the scope of the fix. Don't infer fix breadth from a bounty amount. For any vendor review, ask what changed, which surfaces were touched, when it shipped, and whether customers need to act. Our piece on what OpenAI's frontier-model monitoring claim does and doesn't tell you applies the same discipline to another vendor assurance.

Where should teams look for similar AI-generated HTML sandbox risk?

Start with workflows where a signed-in user opens generated HTML. The reported attack involved a share URL visited by an authenticated user. ¹ Analysis: authenticated previews and shared interactive content warrant closer scrutiny than content rendered with no session attached.

Check for paths that let generated content talk to its parent application, including postMessage calls and nested iframe creation. Both appeared in the reported chain. ¹ Other browser-exposed API paths are also worth reviewing as a general security practice.

Treat generated content as untrusted even inside a sandbox tag. Sandboxing was intended to prevent API and data access in this case; parent-page messaging and iframe behavior provided a route around it. ¹

Analysis, engineering checklist: for teams running comparable interactive content, confirm that:

• Message handlers check sender origin and reject unexpected message types.
• DOM updates never pass untrusted strings into innerHTML or similar sinks.
• Iframes carry restrictive sandbox attributes that can't be loosened by injected markup.
• Allowed script-source domains are reviewed for endpoints that can reflect content back as executable code.
• Preview content has no unnecessary route to authenticated APIs or user-specific data.

These are recommendations inferred from the reported failure pattern, not confirmation of what OpenAI's fix does. ¹

One further point is analysis rather than something the report states. Controls at the model-access layer, such as an enterprise AI gateway, govern which models and providers your applications call. They don't replace review of how your own front end renders what comes back.

What to do this week

Inventory every place a user can open AI-generated interactive content while signed in: share links, embedded previews, and anything rendered inside the authenticated session. The reported scenario involved a share URL visited by a signed-in user. ¹

Trace your own trust boundary end to end: which frames can send messages, how handlers validate origin, where message data lands in the DOM, how nested frames get created, which script domains are allowed, and whether any of that content can reach private APIs. ¹

Put these questions to any vendor running similar previews: what exactly was fixed, which product surfaces were affected, when did the fix ship, and is any customer action required. The source report provides no technical details on the fix or its timing. ¹ For a broader view of the evidence to request, see provider evidence on the procurement agenda.

Keep your own incident notes in four separate columns: code execution demonstrated, private data access demonstrated, account actions demonstrated, and real user impact confirmed. The report describes capabilities but does not confirm real-user impact. ¹ Watch for whether OpenAI or Parameter Labs publishes technical detail that fills in the remaining gaps.