A public ChatGPT share link could run an attacker's code inside the session of any signed-in user who opened it and read that user's private conversations, according to a write-up by the security firm Parameter. OpenAI rated the flaw P1, its most serious category according to The Hacker News, and fixed it on October 26, eight days after the report, the researchers said.

Parameter said it reported the chain through OpenAI's bug bounty program on October 18 and was paid a total of $5,000. The Hacker News reported the findings on October 31. Parameter does not report any use of the flaw against real users; its proof ran between separate accounts.

How the attack worked

The chain joined several features that were each reasonable on their own, the researchers wrote. In order:

  1. The attacker publishes a ChatGPT conversation that holds an HTML Preview and an interactive graph, and shares its public link.

  2. Drawing the graph loads MathLive, a math keyboard library, into the main chatgpt.com page, where it listens for messages from other frames without checking who sent them.

  3. The Preview, which runs in a locked-down frame on a separate address, sends that listener raw HTML dressed up as keyboard layout data.

  4. The HTML creates a new frame that is not sandboxed and that the browser treats as part of chatgpt.com.

  5. ChatGPT's content security policy blocked inline code but allowed scripts from YouTube, and a YouTube endpoint supplied the code that ran in the new frame.

  6. The code calls ChatGPT's signed-in APIs as the victim. Parameter listed recent conversations, opened a private chat never shared with the attacker account, and sent a small piece of it to its own server.

In the first version a victim had to click Preview once. Parameter later made Preview open by itself, writing that "opening the shared link was the only required action." On the reach of the attack, it wrote: "Essentially, we could perform any action on behalf of the victim's ChatGPT account."

Parameter announced the findings on X on October 30, describing a takeover that reached private chats, files and settings:

Post on X by @parameter_ai

We hacked ChatGPT (using ChatGPT). We demonstrated that a single shared link could take over the account of anyone who opened it: private chats, files, settings, all of it. OpenAI rated it P1 and fixed it Oct 26.

Who was exposed

Anyone signed in to ChatGPT on the web who opened a malicious share link, until the fix. Parameter said it confirmed delivery "between separate accounts and workspaces," but the write-up does not say which ChatGPT plans were affected and gives no count of exposed users. The link could arrive by email, chat, a support ticket or a social post, The Hacker News reported.

Two versions of ChatGPT's web frontend carried the flaw, and OpenAI fixed them at different times, according to the write-up.

The disclosure timeline

Date

Day

What happened

Oct. 13

-5

Parameter confirms the MathLive message-to-HTML path against ChatGPT's live code

Oct. 18

0

Report filed with OpenAI's bug bounty

Oct. 21

3

OpenAI reproduces it and raises it from P2 to P1

Oct. 22

4

One web frontend fixed

Oct. 23

5

Security policy change blocks part of the chain

Oct. 26

8

Both frontends fixed; $5,000 bounty

Oct. 28

10

Parameter's write-up is dated

Source: Parameter's write-up; days counted by SaasBuzz from the report date.

What users and admins should do

Nothing needs installing. The fix is on OpenAI's side, "with nothing to install or reset," The Hacker News reported, adding that ChatGPT users do not need to do anything. OpenAI had not published a statement or advisory on the report that SaasBuzz could find by 11:15 a.m. UTC on October 31; the account of its response here comes from Parameter's write-up.

For teams that build features like ChatGPT's Preview, Parameter set out four lessons:

  • A message receiver should check both the sender's web address and the exact window it gave permission to.

  • Settings passed between windows should never carry raw HTML.

  • A frame created on the fly should stay sandboxed when an untrusted frame can shape its content.

  • A content security policy is a backup control, not the only barrier once attacker HTML reaches the main site.

What it means for companies that use ChatGPT at work

It is not the first time this year that researchers have shown one chatgpt.com link acting inside a victim's signed-in session. In July, Zenity Labs described AgentForger, a flaw that turned "a regular chatgpt.com link into a way to drive the Builder without further user interaction," and wrote that OpenAI resolved it within four days of disclosure. Parameter's chain took eight days from report to full fix, twice as long, with one frontend closed on day four.

In both cases the bait was a link on OpenAI's own domain, the kind staff have little reason to distrust, and a shared conversation is content anyone can write. Parameter also wrote that because its code ran with the web app's signed-in access, "its reach was not inherently limited to the conversation endpoints used in our proof."

The fix also shows where the weakness sat. The October 23 policy change blocked part of the chain, but the flaw closed only when both frontends rejected the messages themselves. Parameter wrote that "the YouTube response was the final workaround for CSP, not the root cause": the root was a third-party library in the main page that trusted messages from any frame. For buyers, that is a question to put to any AI chat vendor that renders shared or generated content: which libraries run beside the user's session, and what they accept.