A Shared ChatGPT Link Could Expose Private Chats

Imagine clicking a link to a shared ChatGPT conversation. You expect to read a discussion someone sent you. Instead, that single click could allow malicious code to access private conversations in your own ChatGPT account.

That was the risk demonstrated by security researchers at Parameter in a vulnerability report published on October 28, 2026.

According to the report, a specially crafted shared conversation link could be used to execute attacker-controlled code inside a victim's logged-in ChatGPT session. The researchers demonstrated that the code could access private conversations that had never been shared with the attacker.

OpenAI reportedly fixed the vulnerability on October 26, eight days after receiving the report, and assigned it a P1 severity rating.

The discovery highlights an important security lesson: even a familiar feature, such as sharing a link, can become a potential attack path when different parts of a web application interact in unexpected ways.

Let's break down what happened, how the attack worked, and what it means for ChatGPT users.

What Was the ChatGPT Vulnerability?

The vulnerability involved ChatGPT's shared conversations and its Preview feature, which can display interactive web content generated from HTML.

According to Parameter, an attacker could create a malicious shared conversation containing specially crafted content. When a victim opened the link and interacted with the Preview feature, the attack could cross a security boundary that was supposed to isolate that content.

In the most reliable version described by the researchers, the victim needed to click the Preview button once. A later version of the demonstration reportedly triggered Preview automatically, making opening the link the only required action.

The potential impact was serious.

Because the malicious code could execute within the victim's authenticated ChatGPT session, it could make requests with the same account access available to the legitimate website.

The researchers demonstrated accessing recent conversations, opening a private chat, and sending a small portion of its contents to a server they controlled for the test.

Importantly, Parameter described this as a controlled proof of concept. Its report did not establish that attackers had exploited the vulnerability against real users.

How Could a Shared Link Become an Attack?

The interesting part of this vulnerability is that the attack did not rely on a traditional malicious download.

The researchers described a chain involving several components that were not sufficiently isolated from one another.

1. The Attacker Creates a Malicious Conversation

The attack started with an ordinary-looking shared ChatGPT conversation.

A link like this could be distributed through familiar channels, including email, messaging applications, support tickets, or social media.

That is what made the scenario concerning: the delivery method could look similar to a legitimate shared conversation.

2. Preview Runs Interactive Content

ChatGPT's Preview feature can turn HTML content into a small interactive web page.

Because HTML can contain executable code, the content must be isolated from the main application.

This isolation is commonly called a sandbox.

Think of a sandbox as a separate room. Code running inside it should not be able to reach into the rest of the application and access private information.

According to Parameter, the Preview content was initially isolated as intended. The researchers found a different route through another component on the page.

3. A Message Listener Failed to Verify the Sender

The shared conversation also contained an interactive graph.

Rendering that graph loaded a mathematical interface library called MathLive into the main ChatGPT page.

According to the researchers, MathLive had a message listener that accepted messages related to its on-screen keyboard without adequately verifying which browser frame had sent them.

This distinction matters.

Web applications often use messages to let different components communicate. However, if a component accepts messages from an untrusted source, an attacker may be able to make it perform an action it should never allow.

Parameter found that the relevant message could carry raw HTML as part of the keyboard-layout data.

That created the opportunity to cross the intended security boundary.

4. The Attack Escaped the Intended Isolation

The researchers reported that the crafted message allowed HTML to create a frame that was not properly sandboxed and inherited the identity of the main ChatGPT website.

This was the critical step.

Instead of remaining isolated within the Preview environment, the attack could execute code with the privileges associated with the trusted website.

The demonstration then used a script hosted on YouTube to supply the code.

ChatGPT's Content Security Policy, or CSP, restricted where scripts could be loaded from. However, according to the report, it blocked inline scripts while allowing scripts from YouTube.

The YouTube component was therefore part of the exploit chain, but Parameter identified the insecure message handling and frame creation as the more fundamental problems.

Simply blocking one script source would not necessarily have fixed the underlying vulnerability.

What Could an Attacker Access?

The demonstrated impact went beyond viewing the shared conversation.

According to Parameter, the researchers were able to use the victim's authenticated session to interact with ChatGPT's own APIs.

Their proof of concept reportedly demonstrated the ability to:

• List the victim's recent conversations.
• Open a private conversation that had not been shared with the attacker.
• Extract a small portion of that conversation
• Send the extracted information to a server controlled by the researchers.

The researchers also stated that the vulnerability could potentially allow actions to be performed on behalf of the victim's ChatGPT account.

That does not mean every possible action was individually demonstrated or that real-world accounts were compromised. It describes the potential reach of code operating with the victim's authenticated access.

The distinction is important when evaluating security reports: a demonstrated proof of concept establishes what researchers were able to reproduce, while broader impact statements describe what the underlying access might permit.

Three Security Weaknesses Came Together

The report identified three key design problems that combined to make the attack possible.

1. Insufficient message validation

The MathLive listener did not adequately verify the origin of the message before acting on it.

2. Untrusted HTML in message data

The message could contain raw HTML, allowing data intended for one purpose to become a vehicle for creating web content.

3. An improperly isolated frame

The resulting frame was not sandboxed as required and inherited the identity of the trusted ChatGPT website.

The YouTube-hosted script helped complete the attack, but it was not the root cause identified by the researchers.

This is a useful lesson for developers. Security problems often arise not because one component is obviously broken, but because several individually familiar features interact in an unsafe way.

A message listener, an HTML renderer, a browser frame, and a content security policy all serve legitimate purposes. Their combined behaviour, however, can introduce risks that are difficult to spot when each component is examined in isolation.

How Did OpenAI Respond?

According to Parameter's report, the researchers submitted their findings through OpenAI's bug bounty program on October 18, 2026.

The timeline described in the supplied report is:

• October 18: Parameter reported the vulnerability.
• October 26: OpenAI deployed a fix across two versions of its web frontend.
• October 28: Parameter published its technical write-up after the fix.

The report states that OpenAI reproduced the issue, increased its severity rating from P2 to P1, and paid a total bounty of $5,000.

P1 was described as the highest severity category in this report.

Parameter also stated that the updated frontend versions rejected the messages required for the attack.

The reported eight-day turnaround shows why responsible vulnerability disclosure matters. Researchers can investigate a security weakness, report it privately, allow the developer to address it, and publish the technical details after a fix is available.

Do ChatGPT Users Need to Do Anything?

According to the supplied report, users do not need to install anything or reset their accounts because the fix was implemented on OpenAI's side.

Nevertheless, the incident offers a few useful security habits.

Be careful with unexpected links. A shared conversation may look harmless, but you should still consider who sent it and why.

Pay attention to unusual behaviour. If a website behaves unexpectedly after you open a link, avoid interacting further until you understand what is happening.

Keep your browser updated. Browser security updates help protect against a range of web-based threats, even though they are not a substitute for fixing a vulnerability in a website.

Understand what you are authorizing. When connecting applications or granting permissions, consider whether the access requested is necessary.

These are general precautions, not special steps required to address this particular vulnerability.

The Bigger Lesson for AI Security

AI applications are becoming more than simple chat windows.

They increasingly support interactive previews, file access, integrations, browser-based tools, and connections to external services.

These features make AI products more useful, but they also introduce more components that must work together securely.

The ChatGPT vulnerability described by Parameter illustrates an important principle: isolating untrusted content is not enough if another component can carry that content across the security boundary.

Developers building AI-powered applications should pay particular attention to message-origin validation, HTML handling, iframe sandboxing, and content security policies.

Security testing should also examine how components interact, rather than evaluating each feature only in isolation.

For users, the incident is a reminder that security depends on more than passwords and two-factor authentication. The way a website handles content and permissions matters too.

Final Thoughts

A shared ChatGPT link should be a convenient way to exchange a conversation, not a route into someone's private account.

According to Parameter, a chain of weaknesses involving Preview, MathLive, and browser frame isolation made that risk possible. OpenAI reportedly fixed the issue eight days after it was reported, before the technical write-up was published.

There is no evidence in the supplied report that the vulnerability was exploited against real users, and users do not need to take special action for the reported fix.

Still, the incident provides a valuable lesson for the wider AI industry.

As AI products gain more capabilities, their security boundaries become increasingly important. Features that let AI applications display interactive content or communicate with other tools must be designed with the assumption that untrusted input may try to cross those boundaries.

Convenience makes an AI product useful. Strong security helps make it trustworthy.

Show some love. 🫰 Buy Me A Coffee. https://buymeacoffee.com/dibeeshks

Follow me on LinkedIn https://www.linkedin.com/in/dibeeshks/

Follow me on Twitter https://x.com/dibishks/