ChatGPT Sandbox Breached: How a Complex Attack Chain Stole Account Data

When the "Sandbox" Is No Longer Safe: The ChatGPT Account Takeover Vulnerability Discovered by Parameter Labs

Sandboxing has always been one of the most critical lines of defense in the browser security model. When ChatGPT began supporting the rendering of interactive HTML applications within conversations, OpenAI placed this content inside a restricted iframe, expecting that untrusted code would be unable to reach user data and platform APIs. But research from Parameter Labs shows that this defense line once had gaps—and the gaps did not come from some obvious design flaw, but from a chain of seemingly harmless components stacked together.

According to the analysis disclosed by Parameter Labs, they found a rather complex attack chain whose ultimate consequence was this: an attacker could construct a ChatGPT share link, and any logged-in user who clicked it could have private data stolen or actions performed on their behalf. OpenAI fixed the vulnerability and paid a $5,000 bug bounty.

Attack Chain Breakdown: A Chain Reaction Across Four Stages

Stage One: The postMessage Entry Point of the MathLive Virtual Keyboard

OpenAI used MathLive, a JavaScript math input library, for graphics support. MathLive ships with a virtual keyboard component, and this keyboard can be triggered by the parent page via postMessage()—and the message source can be an iframe inside the sandbox.

The problem is that the code receiving the message used innerHTML to render content. This means any code capable of sending a message could inject custom HTML into the parent page. More critically, at the time there was no mechanism preventing other sandboxed iframes (including the HTML preview iframe) from invoking this method. A component intended to provide convenient math formula input had accidentally become a data entry point across a trust boundary.

postMessage and Cross-Origin Communication

postMessage() is a cross-document communication API introduced in HTML5 that allows windows of different origins (including iframes and parent pages) to safely pass messages between each other. Its original design intent was to break the strict isolation of the same-origin policy and let embedded third-party content collaborate with the host page. But its security depends entirely on the receiver validating the message origin (event.origin) and message content. If the receiver does not check the origin, any context capable of sending a message to that window—including a malicious iframe—can trigger its message-handling logic. This is exactly the problem with the MathLive virtual keyboard: it exposed a postMessage interface but did not restrict caller identity, allowing untrusted code inside the sandbox to drive components in the parent page.

Stage Two: innerHTML Bypasses Sandbox Restrictions

innerHTML itself does not directly execute <script> tags, which is why it is often mistakenly considered "relatively safe." But the attacker does not need to execute scripts directly—they can inject a new iframe without the sandbox attribute. This new iframe is no longer bound by the original sandbox, equivalent to opening an unlocked side door inside a restricted environment.

This step is the turning point of the entire attack chain: upgrading from "can only inject static HTML" to "can control an unrestricted browsing context."

The iframe sandbox Attribute

sandbox is an HTML attribute of iframe used to impose a series of restrictions on embedded content, such as disabling script execution, disabling form submission, and disabling access to the parent page DOM. When an iframe has the sandbox attribute, the browser treats it as an opaque origin and disables multiple capabilities by default; only explicit allow-* tokens can restore specific permissions. ChatGPT's HTML preview relies on exactly this mechanism to isolate untrusted code. However, if an attacker can inject a new iframe via innerHTML without adding the sandbox attribute, this new iframe is completely free from the original sandbox constraints—equivalent to creating a child context with full browser privileges inside a restricted environment, thereby achieving sandbox escape.

Stage Three: The Accidental Combination of CSP and YouTube oEmbed

OpenAI's Content Security Policy (CSP) blocked inline scripts and allowed scripts to load only from a small number of domains. This should have been a very strong layer of protection. But the allowlist included YouTube—and YouTube's oEmbed endpoint could be used to reflect JavaScript and cause it to execute in the page context.

In other words, the strictness of CSP was bypassed by a legitimate third-party service. This is not a CSP misconfiguration, but an inherent weakness of the allowlist mechanism when faced with third-party endpoints that can reflect content.

CSP and JSONP/oEmbed Reflection

The Content Security Policy (CSP) restricts the sources from which a page can load and execute scripts through directives such as script-src, and is one of the core mechanisms for defending against XSS. But a CSP allowlist only validates the source domain of a script, not the content of the script. If a domain on the allowlist provides an endpoint that reflects user input (for example, the YouTube oEmbed interface can return JSON/JSONP responses containing user-controllable content based on parameters), an attacker can construct a URL pointing to that endpoint and make the browser load, from a "trusted" domain, a piece of JavaScript that is actually controlled by the attacker. This technique is often called JSONP hijacking or reflected script injection. It reveals a fundamental contradiction: the trust granularity of an allowlist is the domain, while the trust granularity of a reflectable endpoint must be fine-grained down to specific paths and parameters.

Stage Four: Data Exfiltration and Account Takeover

Once the attacker gains JavaScript execution privileges on the ChatGPT page, subsequent operations become straightforward: call APIs to obtain the user's private data, then exfiltrate the data via image references. The final product is a seemingly normal ChatGPT share URL, but visitors unknowingly trigger the entire attack chain.

Why the $5,000 Bounty Sparked Controversy

In Parameter Labs' disclosure, the authors stated bluntly that the $5,000 bug bounty was "a bit cheap" for a vulnerability of this severity. This assessment deserves serious consideration.

From the perspective of attack complexity, this chain involves chaining together four independent stages, and both discovery and exploitation require deep understanding of the browser security model, CSP mechanisms, and third-party service behavior. From the perspective of impact, the vulnerability affects ChatGPT's sharing feature—a feature designed precisely to let links spread widely. Any logged-in user who clicks a malicious share link could be affected, with no additional interaction required.

The bounty amount itself is a signal. It reflects both the platform's internal rating of vulnerability severity and affects security researchers' willingness to disclose. For vulnerabilities involving account takeover and data exfiltration, $5,000 is indeed low in the bounty systems of large industry platforms.

Implications for Sandbox Design in AI Products

The value of this incident goes beyond a single fixed vulnerability. It reveals the structural risks AI products face when integrating rich interactive capabilities.

Third-Party Libraries Are Part of the Trust Boundary

MathLive's virtual keyboard itself had no vulnerability—its postMessage interface is a normal design. The problem is that when this library is embedded in an environment requiring strict isolation, its message-receiving logic becomes an attack surface. AI products rely heavily on third-party UI components, and each component may introduce new cross-context communication channels, each of which needs to be incorporated into the threat model.

An Allowlist Is Not the Same as Security

A CSP allowlist is a common simplification strategy: as long as the script comes from a trusted domain, let it through. But the YouTube oEmbed example shows that certain endpoints on trusted domains can become vehicles for reflected content. Security design needs to consider not only "who provides the script," but also "which endpoints on this domain can be manipulated."

Sandbox Nesting Requires Escape-Prevention Design

Injecting a new iframe via innerHTML is dangerous because the new iframe is not bound by the original sandbox. Any mechanism that allows untrusted content to create browsing contexts must ensure that the new context inherits equal or stricter restrictions. This is easily overlooked under the single-layer sandbox assumption.

The General Pattern of Sandbox Escape

Sandbox escape usually does not rely on a single vulnerability, but exploits a chain of "capability escalation": starting from a restricted context, gaining the ability to create new contexts through some legitimate interface, and then letting the new context inherit fewer restrictions. Common escape paths include: injecting an iframe without sandbox via innerHTML or document.write; using window.open to open a new window (new windows are by default not bound by the original sandbox); and using postMessage to trigger higher-privilege components in the host page. The core principle for defending against such escapes is the "monotonicity of restrictions": the privileges of any new browsing context created by untrusted content must not exceed those of its creator. In implementation, this requires allowlist filtering of injection points, interception of window.open and iframe creation, and strict origin validation when the host page handles cross-context messages.

Conclusion

Parameter Labs' discovery is a typical chained vulnerability exploit: there was no single point of failure, but the four stages linked together formed a complete account takeover path. OpenAI's fix and bounty payment indicate that the vulnerability has been addressed, but the design patterns exposed in the attack chain—cross-context communication in third-party components, reflectable endpoints on allowlists, and escape risks in nested sandboxes—are instructive for all AI products that integrate rich interactive content into conversational interfaces.

The security of a sandbox does not depend on how strict it is, but on whether its interactions with other components are fully modeled and tested.