A public ChatGPT share link could run attacker code in your session

A malicious public ChatGPT share link could run an attacker’s JavaScript inside the logged-in session of anyone who opened it, according to a write-up by security firm Parameter. OpenAI fixed the flaw on October 26 and paid a $5,000 bounty, as The Hacker News reported.

One click, and the code runs as chatgpt.com

Parameter’s researcher describes a chain that let a public share execute JavaScript with the chatgpt.com origin in the victim’s session. The only action required from the victim was opening the link. In the most reliable version, ChatGPT’s HTML Preview started on its own about 4.5 seconds after the page loaded, according to Parameter.

The write-up lays out five steps. The attacker publishes an ordinary-looking conversation that contains a graph and an HTML Preview. The graph loads the MathLive math library, which registers a postMessage listener on the main ChatGPT page. The sandboxed Preview then sends messages to that listener. Parameter says MathLive accepted them without checking who sent them, so the attacker could swap in HTML in place of a keyboard layout.

MathLive inserted that HTML without sanitizing it, which created an unsandboxed iframe that inherited the chatgpt.com origin. ChatGPT’s content security policy (CSP) blocks inline scripts, but it allows YouTube. Parameter says the attacker used a YouTube oEmbed JSONP response to run code inside the frame anyway.

What the researcher actually showed

Parameter says the injected code ran with the victim’s authenticated session. In its demonstrations, the code listed recent conversations, retrieved the content of a private conversation that was never shared with the attacker, and sent a small selected value to an external server. The write-up adds that the code could in principle reach any action available through ChatGPT’s authenticated frontend APIs, including account actions, but it does not say those were tested.

Parameter also published the timeline. It says it confirmed the vulnerable path in production code on October 13 and submitted the report to OpenAI’s bug bounty program on October 18. OpenAI reproduced the issue on October 21 and raised its severity from P2 to P1. One frontend was fixed on October 22, CSP changes blocked part of the chain on October 23, and OpenAI confirmed both frontends were fixed on October 26. According to Parameter, OpenAI said both web frontends now reject the cross-frame messages.

Why a CSP did not stop it

The case is a reminder of how safety boundaries in web apps can fail at the seams between features. Parameter argues that the CSP was not the root cause: it was bypassed through an allowed third-party endpoint, and blocking only that endpoint would have left the HTML injection path open. Its stated lessons are to check both event.origin and event.source before accepting state-changing messages, to refuse raw HTML in cross-window settings, to keep dynamically created documents sandboxed, and to treat a CSP as defense in depth rather than the only barrier.

The exposure matters because of what ChatGPT histories hold. A share link is designed to be passed around and opened by strangers, so the attack needed no phishing page, only a link of the kind people already exchange. The same pattern of trusted tooling being turned against users showed up this week in our report on a tampered Claude Code extension that came through Cursor’s marketplace.

OpenAI’s bug bounty rated this as its most serious category, and the $5,000 payout was paid for the combined chain. Parameter’s description of the severity change, from P2 at first triage to P1 after reproduction, is the clearest public sign of how OpenAI judged it.

What users need to do, and what is not established

Because the fix is server-side, users do not need to update anything or change settings. Links created before the fix no longer carry the risk, according to the timeline in Parameter’s report, which says both frontends now reject the malicious messages.

Several points remain unconfirmed. The account comes from Parameter, and OpenAI’s own statements are only relayed through that write-up; the Hacker News article could not be opened for this report, so its additional details are not covered here. One secondary report states there was no evidence of real-world exploitation, but this has not been verified independently, and the sources do not say whether OpenAI has checked its logs for abuse before the fix. Parameter has also kept the exploit payload and request-level details out of its summary.

For now, the practical advice is limited to what the sources support: the specific chain has been closed, and there is nothing users must do. Anyone who handles sensitive material in ChatGPT may still want to treat links from unknown people with the same caution as any other web link.