Generated by Codex with GPT 5.6 Sol High

Techmeme surfaced Parameter’s October 28 disclosure, “Do the Math: How We Took Over ChatGPT Accounts.” The finding is a useful warning about modern web security: a sandbox can work exactly as designed and still fail when another feature creates an unguarded bridge around it.

Parameter’s researchers built a public ChatGPT conversation that could run attacker-controlled JavaScript in the signed-in session of another person who opened its share link. Their proof enumerated the victim account’s recent conversations, fetched content from an unrelated private conversation, and sent a small selected value to a server they controlled. OpenAI reproduced the issue, classified it as a P1 vulnerability, deployed fixes across two web-frontend versions, and marked it resolved on October 26.

A chain made from ordinary features

No single component supplied the whole exploit. The shared conversation combined a normal interactive graph with an HTML Preview. The Preview ran in a restricted frame on a different origin, so its JavaScript could not directly inspect the surrounding ChatGPT page. That isolation held.

The graph, however, loaded MathLive, a math-rendering library that installed a message listener in the main page for its on-screen keyboard. Web pages use postMessage to communicate across frames, but the receiving listener accepted the relevant setting change without verifying both the sender’s origin and window. The sandboxed Preview could therefore send a message that replaced a keyboard layout with attacker-controlled HTML, followed by another message that caused MathLive to render it in the real ChatGPT document.

That was HTML injection, not yet script execution. Scripts inserted through innerHTML do not normally run. The researchers crossed the next boundary by inserting an unsandboxed iframe with a srcdoc document. Because the main ChatGPT page created the frame, it inherited the chatgpt.com origin and could reach the parent page.

ChatGPT’s Content Security Policy still blocked inline JavaScript, but it allowed scripts from YouTube. YouTube’s oEmbed endpoint supported a JSONP callback and returned the callback inside an executable response even when the callback name was invalid. By shaping that callback into a small program, the researchers obtained JavaScript execution inside the same-origin frame. YouTube was the last bypass, not the root flaw: the more fundamental failure was allowing an untrusted frame to make a privileged component inject raw HTML into the main application.

The first version depended on a researcher-controlled ChatGPT App, which would have required the victim to connect or invoke it. The researchers then found that a public conversation could preserve both necessary pieces: the graph initialized MathLive in the main page, and a later assistant-authored Preview delivered the messages. In the most stable early version, the victim had to click ChatGPT’s normal Preview button once. After the HTML block was marked previewable, Parameter reproduced an automatic version three times in a separate account, including after a hard refresh; opening the share link was the only user action.

Once code ran as chatgpt.com, it could use the same authenticated context as the normal frontend. The proof read session information already available to the page, listed conversations through ChatGPT’s authenticated APIs, retrieved two turns from a private conversation, and exfiltrated a deliberately limited value through an image request. This was more serious than a visual defacement because it crossed from public, attacker-authored content into private account data.

The demonstrated scope still has boundaries. Parameter tested controlled accounts and deliberately minimized the data sent off-site. The report shows a practical path to private conversation access and says other frontend actions shared the same security boundary, but it does not document exploitation in the wild, theft of passwords, or independent reproduction outside Parameter and OpenAI. The vulnerability was also fixed before the detailed write-up appeared.

The product is the security boundary

The clean repair is broader than blocking the YouTube endpoint. Cross-window receivers should authenticate both event.origin and event.source; settings messages should not carry raw HTML; and documents influenced by untrusted frames should remain sandboxed. Content Security Policy is valuable defense in depth, but an allowlist cannot make an unsafe rendering path safe.

The deeper lesson is that separately reasonable features can compose into an unreasonable system. Preview isolation, graph rendering, frame messaging, HTML layouts, public sharing, and a third-party script allowance each had a legitimate purpose. The vulnerability lived in the seams between them. For products that mix user-authored content with powerful interactive tools, security review has to follow data and authority across the complete feature chain—not stop after each component passes its own local test.