How Researchers Took Over ChatGPT Accounts With a Single Link
November 1, 2026
In October 2026, a research team at Parameter Labs found a way to take over anyone's ChatGPT account simply by sending them a link. No app installation, no code to paste, no developer tools required. The victim only had to open a shared ChatGPT conversation. OpenAI fixed the issue on October 26 and classified it as P1, their highest severity [1].
The attack chain started with two features that looked harmless on their own: an interactive graph and an HTML Preview. ChatGPT can turn an HTML code block into a small working webpage using its Preview feature. Since that page may contain arbitrary code, ChatGPT runs it inside a restricted frame on a different web address. The Preview can run JavaScript, but the browser treats it as a different website, so it cannot directly inspect the signed-in ChatGPT page around it [1].
That isolation appeared to work exactly as intended. Code inside the Preview could not read the parent document. That should have been the end of it.
But the conversation also contained a normal interactive graph. Behind the scenes, the graph loaded a math library called MathLive. Loading it did more than draw the graph. It also installed a listener in the main ChatGPT page for messages related to MathLive's on-screen keyboard. Browsers call this API postMessage. It is a legitimate way for two frames to exchange information even when the browser prevents them from reading each other's pages [1].
You can think of it as a mail slot. The restricted Preview cannot walk into the main page, but it can still drop a message through the slot. That is safe only if the receiver checks who sent the message. MathLive did not make that check for the setting the researchers were interested in. Its listener accepted a message that changed the virtual keyboard layout, and that layout was allowed to contain HTML [1].
The graph had installed the receiver. The Preview gave them an untrusted sender. Two unrelated features had accidentally created a path across the sandbox.
The Preview sent two messages. The first replaced a virtual keyboard layout with attacker-controlled HTML. The second told MathLive to show the keyboard, causing it to render the new layout. The HTML executed as chatgpt.com with access to the victim's authenticated web session [1].
The researchers confirmed that the payload could enumerate the victim's conversation list, retrieve content from a private conversation that had never been shared, and send data from that conversation to an external server. The payload was not limited to modifying the page or displaying an alert. It could directly call ChatGPT's authenticated APIs as the victim, essentially allowing full account takeover [1].
This is a textbook example of a vulnerability class that keeps appearing in complex web applications: two features that are individually safe create an unsafe interaction when combined. The sandbox was correct. The postMessage channel was legitimate. The bug was that the receiver trusted the sender without verification, and the sender lived on the wrong side of the sandbox boundary [1].
OpenAI fixed the issue within days of the report. The MathLive listener now validates the origin of incoming messages. But the structural lesson is broader. Every postMessage listener is a potential sandbox escape if it does not check who is talking to it. And every third-party library loaded into a privileged context is a new attack surface that the application developers did not write and may not fully understand [1].
Sources: [1] Do the Math: How We Took Over ChatGPT Accounts, Parameter Labs, Mukul Goyal, October 28, 2026