How We Took Over ChatGPT Accounts

Summary

A research report summarized by Simon Willison describes how Parameter Labs chained weaknesses in ChatGPT's HTML-preview implementation to execute JavaScript in the ChatGPT context. The reported delivery mechanism was a crafted ChatGPT share link: visiting it while signed in could expose private account data or allow actions on the visitor's behalf. The supplied evidence describes vulnerability research, not an observed malicious campaign.^[0]

The chain crossed several security boundaries. A MathLive virtual-keyboard message handler accepted messages from sandboxed preview frames and inserted HTML into the parent page. That insertion enabled an unsandboxed iframe, after which a YouTube oEmbed endpoint provided a way around the reported script-source restrictions. With JavaScript running in ChatGPT, the researchers could retrieve private data through APIs and exfiltrate it through an image reference.^[0]

OpenAI reportedly closed the vulnerability and awarded a $5,000 bounty. These exploit and remediation details come from the supplied secondary report; the underlying Parameter Labs research text is not included. OpenAI's supplied help article confirms that supported previews use a sandboxed environment, but does not independently confirm the exploit, fix, affected versions, or remediation date.^[0][4]

Attack chain

1. 1. Shared-content delivery: The reported exploit could be packaged in a ChatGPT share link for another signed-in user to visit. The attacker-controlled content was associated with an HTML preview rendered inside a sandboxed iframe.^[0]
2. 2. Parent-page message-handler abuse: Code in the sandboxed preview could send a postMessage to the parent page's MathLive virtual-keyboard handler. The report states that no mechanism prevented HTML-preview frames from invoking this handler, which used innerHTML to insert supplied HTML into the parent.^[0]
3. 3. Unsandboxed iframe creation: Although script elements inserted through innerHTML did not execute directly, the HTML insertion could create a new iframe without sandbox restrictions, providing the next stage of the reported escape.^[0]
4. 4. Script-source restriction bypass: ChatGPT's reported Content Security Policy blocked inline scripts and restricted external script sources. The researchers used a YouTube oEmbed endpoint to reflect JavaScript from an allowed source and obtain execution in the ChatGPT context.^[0]
5. 5. Account-context access and exfiltration: The resulting JavaScript execution allowed private data to be fetched from APIs and exfiltrated through an image reference. The report also describes the ability to take actions on the signed-in user's behalf, without detailing specific actions.^[0]

Disclosure timeline

How it works

The intended isolation boundary separated untrusted, interactive HTML previews from the privileged ChatGPT page. OpenAI's help documentation describes code previews as sandboxed, while the exploit summary explains that this isolation was necessary to prevent preview content from interacting with OpenAI APIs and private data.^[0][4]

The initial boundary failure was in cross-frame message handling. MathLive's virtual keyboard could be triggered in the parent page through postMessage, and the receiving code used innerHTML. According to the report, the implementation did not prevent unrelated sandboxed frames, including HTML-preview frames, from invoking that HTML-insertion path.^[0]

HTML injection and JavaScript execution were separate stages. The report explicitly notes that innerHTML did not directly execute inserted script elements. The researchers instead used HTML injection to introduce an iframe without sandbox restrictions, then addressed the remaining Content Security Policy restrictions.^[0]

The reported Content Security Policy prohibited inline scripts but permitted scripts from a small set of sources that included YouTube. A YouTube oEmbed endpoint could reflect JavaScript in a form that executed, allowing the chain to obtain script execution despite those restrictions. The supplied summary does not include the exact policy, request parameters, or exploit payload.^[0]

The demonstrated impact followed from execution in the ChatGPT context: private data could be requested through APIs and sent outward through an image reference. This supports the reported unauthorized data-access and account-action impact, but the supplied evidence does not establish credential theft, persistence, or any specific post-exploitation action beyond those described capabilities.^[0]

Affected versions and patch status

Key takeaways

• This was a multi-stage preview-isolation failure: cross-frame message handling enabled parent-page HTML injection, an unsandboxed iframe advanced the escape, and an allowed external endpoint supplied executable JavaScript.^[0]
• Blocking inline scripts did not prevent the reported exploit because the chain obtained JavaScript through an allowed source. Likewise, the absence of direct script execution through innerHTML did not make the HTML-insertion path safe.^[0]
• The supported impact is private-data access and actions in a signed-in user's context after visiting a crafted share link. The supplied materials do not establish exploitation in the wild, a named malicious actor, or actionable attacker infrastructure.^[0]
• The vulnerability is reported as closed, but exploit mechanics and remediation remain single-source claims in the supplied evidence. The vendor help article corroborates intended sandboxing, not the specific vulnerability or fix.^[0][4]

Defensive actions

• Use the reported closure as the remediation status, while seeking direct vendor confirmation before assigning a precise fix date or affected-version boundary.: The supplied secondary report says OpenAI closed the vulnerability, but provides no deployment identifier or remediation date. The supplied vendor help article describes feature behavior rather than this security fix.^[0][4]
• For implementations using the same pattern, review the MathLive virtual-keyboard message boundary and ensure that untrusted preview frames cannot invoke parent-page HTML insertion.: The reported entry point was a postMessage handler that accepted calls from sandboxed preview frames and used innerHTML in the parent page. This recommendation targets the described boundary failure; the evidence does not identify OpenAI's actual fix.^[0]
• Test HTML-preview isolation against injected descendant iframes, rather than testing only whether inserted script elements execute.: The researchers reportedly advanced the chain by creating an iframe without sandbox restrictions even though innerHTML did not directly execute inserted script elements.^[0]
• Review allowed script sources for endpoints that can reflect attacker-controlled JavaScript, including the reported YouTube oEmbed behavior.: The chain relied on an allowed external source to obtain execution after inline scripts were blocked. This is a targeted review of the demonstrated policy weakness, not evidence that the supplied vendor has retained that policy or endpoint exposure.^[0]