The ChatGPT Share Link Flaw Is an Old Web Bug in a New Setting

The ChatGPT share link flaw looks like an AI story, but at heart it is a plain web security bug, the kind testers have long been finding, and it reached the headlines because the target was ChatGPT. That matters, because it means your own applications can have the same hole.

The ChatGPT share link flaw is an old bug in a new setting

Parameter’s researchers showed that a shared ChatGPT conversation could run their code in a viewer’s signed-in session. That is cross-site scripting, with a twist. The code got into the main page by way of a message listener, not a form field.

Nothing about it needed AI. A maths library called MathLive listened for messages from any sender. An isolated Preview frame sent it HTML. The page built a frame with no sandbox, and the content security policy let a script through from YouTube. Parameter’s write-up has the full chain.

What was at stake

The injected code called ChatGPT’s own APIs as the victim. It listed recent chats and pulled a private one that the attacker had never been sent. The researchers used accounts they controlled and report no real-world exploitation. OpenAI rated the report P1, fixed it by 26 October, and paid $5,000.

The real lesson of the ChatGPT share link flaw

Here is the argument I would make to any board. Most organisations test for flaws inside one feature. Real attackers look at the joins. They ask which component trusts which, and whether that trust is earned.

In this case the Preview pane was well isolated. The graph was fine. The library was behaving as designed. Yet one loose rule on who may send a message turned an isolated frame into a way in. Every part passed its own review.

That has a practical consequence for how you buy security testing. A scan or a checklist tests parts. A skilled tester follows a path through several parts and asks what the combination allows. If your last test was scoped as a list of pages, nobody was asked to look at the joins.

Why scanners miss a bug like this

An automated scanner works by sending known test strings into known inputs and looking for a reflection. This chain had no such input. The payload travelled through a message between two windows, and it only worked once a graph had loaded a particular library in the right page.

A scanner would have struggled here: it would need to know the library existed, that it listened for messages, what format they used, and that a YouTube endpoint could supply script. Parameter reports that it confirmed the message path in ChatGPT’s production code on 13 October and had a working chain the next day. That is a person reading code and testing ideas, not a tool running a list.

The bounty tells its own story

OpenAI paid $5,000 for a bug that, once a victim opened a crafted link, could act as that victim. In my view that is a fair reward for the finder, and small next to the cost of a real incident. For most businesses, there is no bounty programme at all. If a flaw like this sits in your portal, the first person to find it may not be on your side.

The cheapest time to find it is before launch, or before the next big feature goes live. After an incident, the same work costs far more, and you do it under pressure.

There is a fair counter-argument: AI products do add new risks, such as tools that read mail or run code on a user’s behalf, and those deserve their own testing. I agree. But this particular bug did not come from the model. It came from ordinary web plumbing, and Parameter’s advice is ordinary web engineering: check the sender, refuse raw HTML, and keep frames sandboxed. Calling it an AI flaw risks sending teams to look in the wrong place.

The same goes for the way you brief your board. If the message is “AI is dangerous”, the budget goes to AI policy documents. If the message is “our web apps trust each other too much”, the budget goes to testing, which is where this bug would have been found.

What to do this month

• List the places your applications pass messages between frames, windows or services.
• Ask whether each one checks who sent the message, and whether it accepts HTML.
• Check that dynamically created frames are sandboxed.
• Treat your content security policy as a backstop. Here, it allowed a trusted site that also echoed attacker input.

Our guide to cross-site scripting explains the underlying bug class, and the piece on testing SaaS products shows what a full review of a hosted application involves.

Product teams who embed previews, widgets or user content should have that checked by someone who is paid to break it. Talk to us about a scoped test.