OpenAI Patches ChatGPT Flaw Letting Code Steal Data, Awards $5k Bounty

Parameter Labs reported a vulnerability in ChatGPT’s HTML preview feature that allowed attackers to take over user accounts.reported The exploit chain enabled untrusted code to escape sandboxing and interact with the parent page.

The evidence

According to Simon Willison’s report on Parameter Labs’ findings, the attack targeted the artifacts pattern, previously known as Canvas.reported Interactive custom HTML applications are displayed within sandboxed iframes to prevent untrusted code from accessing OpenAI APIs or private data.

Parameter Labs identified a complex attack chain involving the MathLive JavaScript library. OpenAI uses this library for graph support, and it includes a virtual keyboard feature. This keyboard can be triggered in the parent page via postMessage() calls from the sandboxed iframe.

The code handling these messages used innerHTML to process input. This meant any sender could add custom HTML to the parent page. There was no mechanism to prevent other sandboxed frames, including HTML preview frames, from invoking this method.

Untrusted code in an iframe could therefore insert HTML into the parent context. While innerHTML does not directly execute script elements, it allowed the injection of a new iframe without sandbox restrictions. This bypassed the intended isolation of the preview environment.

OpenAI’s Content Security Policy blocked inline scripts and restricted script loading to specific domains. However, YouTube was an allowed domain. Attackers used the YouTube oEmbed endpoint to reflect JavaScript back in a way that executed it.

The result was a shareable ChatGPT URL that could exfiltrate private data or perform actions on behalf of signed-in users. OpenAI closed the vulnerability after the report. The company paid a $5,000 bug bounty for the disclosure.

The decision

The incident highlights the risks of complex dependency chains in sandboxed environments. Allowing postMessage() interactions with libraries that modify the DOM via innerHTML creates significant exposure. Even strict CSP rules can be circumvented if trusted domains reflect executable content.

The takeaway

Sandboxing effectiveness depends on rigorous input validation for all cross-frame communications. Using innerHTML for messages from untrusted sources is inherently dangerous. Developers must ensure that sandboxed contexts cannot influence the parent document’s structure.

Building on this

Developers building interactive HTML previews must isolate sandboxed content from parent-page DOM manipulation. Use textContent instead of innerHTML when processing postMessage() data. Validate message origins and restrict which frames can trigger sensitive functions. Ensure Content Security Policies do not allow trusted domains to reflect executable scripts. Audit third-party libraries like MathLive for unintended side effects in sandboxed contexts.