A shared ChatGPT link could act as the person who opened it

Security firm Parameter showed that a malicious ChatGPT share link could run attacker code inside a logged-in session and read private chats. The report reached OpenAI’s bug bounty on October 18, 2026. OpenAI raised the severity from P2 to P1, its most serious tier, and closed the bug in eight days. By October 26, both affected web frontend versions rejected the messages that made the issue work. The payout was $5,000 in total. Parameter published the write-up on October 28, after the fix.

The recipient opened an ordinary shared chat. In the version Parameter found most reliable, that person clicked Preview once. A later version opened Preview on its own. The account was already signed in at chatgpt.com. The link looked like any other shared conversation.

What the signed-in session could reach

Once the code was running, it called ChatGPT APIs as the signed-in user. Parameter says that included listing chats, opening private conversations that had never been shared, and pulling snippets out of them. The researchers described the reach as essentially any action the account could take. The demonstration stayed between accounts they controlled. No real-world abuse has been reported.

A share link is how people pass a useful answer. When opening it can act as the reader, the vendor’s own domain is the page that has to be trusted. Preview’s sandbox is supposed to be that boundary. In this case the sandbox held. A feature beside it did not.

Three design choices on one trusted page

A MathLive graph feature had left a cross-frame message listener on the main ChatGPT page. The listener accepted messages from any sender, and those messages could carry raw HTML. Preview could place that HTML into the trusted chatgpt.com page. The content security policy still allowed scripts from YouTube, and that allowance is what supplied the code that ran.

Parameter names three choices. MathLive did not check where a message came from. A channel meant for keyboard-layout data could carry HTML. That HTML could create a frame that was not sandboxed and that inherited the chatgpt.com origin. The public write-up is enough to see the shape of the failure. It is not a recipe, and this briefing will not add the message format, the markup, or a link that reproduces it.

The repair follows the cause. Both web frontend versions now reject the messages. Customers do not install a client, clear a cache, or rotate a key. The fix is already on the service.

What to tell users, and what to fix in the next product

For this bug, users need no action. The report arrived October 18. The fixed frontends were refusing the messages by October 26. The public record describes a controlled test, not stolen customer chats.

Builders of similar products should keep the three choices on the review list. Cross-frame listeners need an origin check. A data channel for layout or graphs should carry layout data, and should refuse markup. HTML from that channel should not be able to open a frame that inherits the application origin. A content security policy that still allowlists a large video host is a delivery path once untrusted HTML is already on the page.

Eight days from report to a frontend that refuses the messages is the outcome that matters. Parameter waiting to publish until after that fix is the other half. The size of a $5,000 P1 award will draw its own argument about bounty tables. The operational fact is simpler. A shared link could read chats the recipient had never shared, and a service-side change is what closed it.

This briefing relies on public reporting by The Hacker News and on Parameter’s write-up. It does not include exploit procedures or proof-of-concept detail.