A Shared ChatGPT Link Could Run Attacker Code in a Victim's Session and Read Their Chats

Security researchers at Parameter found a flaw in ChatGPT that let an ordinary public share link run an attacker's code in the signed-in session of anyone who opened it, giving access to the victim's private conversations. The researchers reported the issue through OpenAI's bug bounty program on October 18. OpenAI fixed it eight days later and rated it P1, its most serious category.

What the trap looked like

The bait was a regular ChatGPT conversation shared through its public link. It could be spread like any genuine shared chat: by email, in a chat message, in a support ticket, or in a social media post.

The victim did not need to install anything, join a workspace, or sign in through the attacker. In the most reliable version of the attack, they opened the link and clicked the Preview button once. In a later version, Parameter made the page open Preview automatically, so following the link was the only step.

From there, the attacker's code ran in the user's session with the same privileges as the ChatGPT site itself. In the demonstration, it listed recent conversations, opened a private chat that had never been shared with the attacker, and sent a portion of it to a server controlled by the researchers. The code called ChatGPT's internal signed-in APIs directly rather than scraping the screen. "Essentially, we could perform any action on behalf of the victim's ChatGPT account," the researchers wrote.

The research was a controlled test: the private-chat proof was run between separate test accounts. Parameter does not report any real-world exploitation.

How the code escaped the sandbox

The Preview feature turns an HTML block in a chat into a small web page. Since that page can contain any code, ChatGPT runs it in an isolated frame on a separate address with no access to the main page. The sandbox itself held; the opening came from another feature in the same conversation.

The shared chat included an interactive graph. Rendering it loaded a math library called MathLive into the main ChatGPT page, and MathLive left a message listener running there for its on-screen keyboard. Messaging between frames is safe only if the receiver checks the sender. MathLive did not, and it also allowed raw HTML in the message. As a result, Preview could hand the attacker's HTML to the trusted main page.

That HTML created a new frame that the browser treated as part of chatgpt.com, and the executable code was pulled in by a script from YouTube. ChatGPT's content security policy (CSP) blocked inline scripts but allowed loading from YouTube.

The fix

According to Parameter, OpenAI reproduced both the code execution and the private-chat access, raised the rating from P2 to P1, and shipped a fix across two versions of its web frontend. By October 26, both versions rejected the messages the attack depended on.

The researchers trace the cause to three design choices lining up: MathLive accepted settings-change messages without checking the sender; those messages could carry raw HTML disguised as keyboard-layout data; and that HTML could create an unsandboxed frame that inherited the chatgpt.com identity. The YouTube workaround was only the final step—blocking it alone would not stop an untrusted Preview from pushing HTML into the main site.

Users do not need to do anything: the fix is on OpenAI's side. Parameter published its writeup on October 28, after the flaw was patched. OpenAI paid $5,000 for the report.

Source: The Hacker News