A security flaw in ChatGPT previously allowed a malicious shared conversation link to execute attacker-controlled code inside the browser session of anyone who opened it. Researchers from security firm Parameter demonstrated that the vulnerability could give the attacker access to the victim's signed-in ChatGPT session, including the ability to list recent conversations, open private chats and send portions of those conversations to an external server. The issue was reported to OpenAI through its bug bounty programme on 18 October and was fixed eight days later. OpenAI ultimately classified the vulnerability as P1, its highest severity category.
The Attack Started With An Ordinary Shared Chat Link
The attack could be delivered through a normal public ChatGPT share link, making it particularly dangerous because nothing about the link needed to look unusual. An attacker could distribute it through email, direct messages, support tickets or social media in exactly the same way someone might share a legitimate conversation. The victim did not need to install software, join a malicious workspace or authenticate through a fake login page. In the most reliable version demonstrated by Parameter, the victim only needed to open the shared conversation and click ChatGPT's Preview button once.
A Later Version Needed Only The Link To Be Opened
The researchers later improved the exploit so that the Preview feature opened automatically. With that version, simply opening the malicious shared chat link was enough to trigger the attack without any additional interaction from the victim. This reduced the attack to a single-step action and made the vulnerability significantly more dangerous. Once the link loaded, the attacker's code could begin operating inside the victim's authenticated ChatGPT session.
The Attacker Could Access Private ChatGPT Conversations
After successful exploitation, attacker-controlled code ran with the same browser-level access as the legitimate ChatGPT site. Parameter demonstrated that the code could enumerate a victim's recent conversations, open a private chat that had never been shared publicly and extract a small portion of its contents. The stolen information was then transmitted to a server controlled by the researchers as part of the proof-of-concept. Importantly, the attack was not limited to whatever information happened to be visible on the screen at the time.
The Exploit Used ChatGPT's Own Authenticated APIs
Rather than scraping text from the webpage, the malicious code directly called ChatGPT's signed-in APIs using the victim's existing session. This meant the attack had access to whatever actions the victim's authenticated browser session was permitted to perform. Parameter described the impact as effectively allowing an attacker to perform actions on behalf of the victim's ChatGPT account. The researchers stressed that their testing was controlled and carried out between separate test accounts rather than against real users.
There Is No Evidence The Vulnerability Was Exploited Against Users
Parameter did not report any confirmed real-world abuse of the vulnerability. The private-conversation demonstration was carried out in a controlled environment using accounts created or controlled by the researchers. This means the proof established what an attacker could have done, not that actual ChatGPT users were known to have been compromised. The flaw was disclosed responsibly before Parameter published the full technical details.
The Vulnerability Involved ChatGPT's Preview Feature
The exploit chain began with ChatGPT's ability to transform HTML contained in a conversation into a small webpage through its Preview feature. Because that generated page could contain arbitrary web code, ChatGPT normally placed it inside a restricted browser frame hosted on a separate address. This sandbox prevented the Preview content from directly reading or modifying the surrounding ChatGPT webpage. According to Parameter, that sandbox itself worked correctly and was not the component that failed.
A Second Feature Created The Escape Path
The vulnerability appeared when another interactive feature existed in the same shared conversation. The malicious chat also contained an interactive graph, which caused ChatGPT to load a mathematics library called MathLive into the main ChatGPT webpage. MathLive left behind a message listener responsible for handling communication related to its on-screen keyboard. The problem was that this listener accepted certain messages without properly validating which browser frame had sent them.
The Message Listener Did Not Verify Its Sender
Browser frames frequently communicate through messages, but a receiving page needs to verify that those messages originate from a trusted source. Parameter discovered that the MathLive listener would accept keyboard-related messages from any frame rather than checking where they came from. Even more importantly, those messages were allowed to contain raw HTML as part of the keyboard-layout information. That created a path for the otherwise isolated Preview frame to send attacker-controlled HTML into the trusted ChatGPT page.
Attacker HTML Reached The Main ChatGPT Page
Once the malicious Preview sent the crafted message, the MathLive listener processed the supplied HTML inside the main ChatGPT environment. The injected HTML could then create a new browser frame that was not protected by the same sandbox restrictions as the original Preview. Because of the way the new frame was created, the browser treated it as belonging to chatgpt.com rather than an isolated external origin. This gave the attacker-controlled content access to the authenticated ChatGPT context.
YouTube Was Used To Load The Final Script
ChatGPT's content security policy prevented the attacker from simply placing arbitrary inline JavaScript directly into the page. However, the policy allowed scripts to load from certain trusted external sources, including YouTube. Parameter used a script loaded through YouTube as the final step that supplied executable attacker code inside the newly created frame. This was essentially a workaround around the site's script restrictions rather than the fundamental cause of the vulnerability.
The Core Problem Was Not YouTube
Blocking YouTube alone would not have fully solved the security issue. The deeper problem was that untrusted content inside Preview could pass raw HTML into the trusted main ChatGPT page through the MathLive message handler. As long as that communication path remained available, another technique might have been found to execute or abuse the injected content. Parameter therefore identified the message-handling and frame-trust design as the real weaknesses that needed to be corrected.
Three Design Choices Combined To Create The Vulnerability
The researchers traced the vulnerability to three separate behaviours that became dangerous when combined. First, MathLive accepted a configuration-changing message without verifying which frame had sent it. Second, that message was allowed to contain raw HTML within its keyboard-layout data. Third, the injected HTML could create a browser frame that was not sandboxed and inherited the trusted chatgpt.com origin. Individually, these behaviours may not have produced the same impact, but together they allowed code from an untrusted Preview to break into an authenticated ChatGPT session.
OpenAI Initially Rated The Report P2
Parameter submitted the vulnerability to OpenAI's bug bounty programme on 18 October. OpenAI reportedly reproduced both the code-execution proof and the demonstration showing access to a private conversation. The issue was initially given a P2 classification before OpenAI increased the severity to P1, indicating that the company considered the vulnerability one of the most serious categories of security flaws. The escalation reflected the potential impact of arbitrary actions being performed inside another user's authenticated account.
OpenAI Fixed The Issue Within Eight Days
OpenAI deployed a fix across two versions of the ChatGPT web frontend. By 26 October, both versions were rejecting the malicious messages used by the exploit chain. This effectively closed the communication path that allowed the untrusted Preview frame to push attacker-controlled HTML into the main ChatGPT page. Because the vulnerability existed entirely in OpenAI's web application, individual users did not need to download or install any update themselves.
Users Do Not Need To Reset Anything
No password change, browser update or account reset is required specifically because of this vulnerability. The remediation was implemented on OpenAI's side, meaning the vulnerable behaviour was removed from the ChatGPT web frontend itself. Users can therefore continue using shared conversation links normally without needing to take any special action. Parameter's publication occurred only after the fix had already been deployed.
The Incident Shows Why Cross-Frame Communication Is Sensitive
The vulnerability highlights how dangerous browser-frame messaging can become when origin checks are missing. Modern web applications frequently use multiple embedded frames and third-party components, and these parts often need to exchange messages with one another. If a trusted component accepts messages from any sender, an attacker may be able to cross security boundaries that were otherwise correctly designed. In this case, the Preview sandbox remained intact, but a separate listener effectively provided a bridge around it.
Sandboxing Alone Is Not Enough
The exploit also demonstrates that security cannot rely on a single isolation mechanism. The original Preview frame was deliberately separated from the main ChatGPT page, and that isolation worked as intended. The vulnerability emerged because another feature elsewhere on the page accepted information from the isolated frame without treating it as untrusted. Secure design therefore requires every component interacting across those boundaries to validate both the origin and the content of incoming messages.
Raw HTML Greatly Increased The Impact
Allowing raw HTML to travel through a configuration message significantly expanded what an attacker could do. Plain text or tightly structured data would have created far fewer opportunities for exploitation. Once arbitrary HTML entered the trusted page, the attacker could create new elements and frames and begin looking for additional ways to execute script. Treating raw HTML as data should therefore always involve strict validation and sanitisation when it crosses a trust boundary.
Authenticated Sessions Make Browser Exploits Particularly Dangerous
The severity of the flaw came from where the attacker's code eventually executed. It did not run as an anonymous visitor on a public webpage; it ran in the context of a victim who was already signed into ChatGPT. That meant normal authentication protections had already been satisfied by the legitimate user. Once malicious code reached that context, it could potentially make the same authenticated requests the user was allowed to make.
The Attack Did Not Need To Steal A Password
Traditional account compromise often focuses on phishing credentials, stealing session cookies or persuading users to approve malicious logins. This vulnerability bypassed those approaches entirely by executing inside the already authenticated browser session. The victim's legitimate session effectively became the attacker's access mechanism. That made the malicious shared link particularly deceptive because there was no fake login page or suspicious password request to warn the user.
Shared Links Created A Convincing Delivery Method
ChatGPT shared conversations are designed to be distributed between users, so receiving one through email, messaging or social media would not necessarily appear suspicious. The malicious conversation could look like any other useful or interesting shared chat. This gave attackers a potentially convincing social-engineering vehicle without requiring them to imitate ChatGPT through a separate phishing site. The legitimate ChatGPT domain itself would host the shared conversation.
One Click Initially Triggered The Reliable Exploit
In Parameter's initial reliable proof-of-concept, victims needed to click the Preview button after opening the shared conversation. While this added one interaction step, the action could easily appear normal if the conversation contained HTML content intended to be previewed. Users would have no obvious reason to believe that viewing the Preview could expose their private account data. The later automatic version removed even that requirement.
The Automatic Preview Version Increased The Risk
By configuring the conversation so the Preview opened automatically, the researchers reduced exploitation to simply opening the shared link. This is a much more dangerous attack model because victims do not need to make an additional decision after arriving at the page. The ability to trigger an exploit through a single legitimate-looking URL is one reason web vulnerabilities involving trusted domains receive serious attention. Fortunately, OpenAI corrected the flaw before the technical details became public.
The Bug Bounty Process Worked As Intended
The incident also demonstrates the value of coordinated vulnerability disclosure. Parameter privately reported the flaw through OpenAI's bug bounty programme rather than immediately publishing the exploit. OpenAI was able to reproduce the issue, evaluate its severity and deploy a fix before detailed information was released publicly. This reduced the chance that other parties could use the vulnerability against users while systems remained exposed.
OpenAI Paid A US$5,000 Reward
After the vulnerability was reported and fixed, OpenAI paid Parameter a total bug bounty of US$5,000. The amount reflects OpenAI's bounty programme rather than the theoretical value of the exploit itself. Security researchers frequently use these programmes to disclose serious vulnerabilities directly to vendors while receiving recognition or financial rewards for their work. Parameter published its complete write-up on 28 October, after the affected ChatGPT frontend versions had already been patched.
There Are No Known Real-World Victims
Parameter's report does not indicate that malicious actors discovered or abused the same vulnerability before it was fixed. The demonstrated private-chat access was performed entirely within the researchers' controlled test environment. That distinction is important because a vulnerability's potential impact can be severe even when there is no evidence anyone was actually harmed. In this case, the research shows what could have happened if an attacker had independently discovered and weaponised the same chain.
The Vulnerability Could Have Reached Beyond Chat Reading
Although the researchers demonstrated access by listing conversations and extracting private chat content, they emphasised that the impact was not limited to reading messages. Because the exploit operated inside the authenticated ChatGPT context, other actions normally available to the user could potentially have been performed as well. The private-chat demonstration simply provided a clear way to prove that the trust boundary had been broken. The broader issue was effectively attacker-controlled activity within the victim's ChatGPT session.
Final Thoughts
The ChatGPT shared-link vulnerability discovered by Parameter was particularly serious because it turned something completely ordinary — opening a shared conversation — into a potential route for account-level compromise. Through a combination of ChatGPT's Preview functionality, an improperly validated MathLive message listener and browser-frame behaviour, attacker-controlled HTML could escape the intended isolation and execute inside the victim's authenticated ChatGPT environment.
Parameter demonstrated that the exploit could list recent conversations, open private chats and transmit information from conversations that had never been shared with the attacker. The attack did not require malware installation, a fake login page or stolen credentials, and a later version could trigger simply by opening the malicious shared link.
OpenAI reproduced the vulnerability, upgraded its severity classification to P1 and deployed a fix across the affected ChatGPT web frontends by 26 October. Users do not need to install anything or reset their accounts because the correction was made entirely on OpenAI's infrastructure.
No real-world exploitation has been reported, and the researchers tested the attack only between controlled accounts. Still, the flaw is a strong example of how seemingly unrelated web features can combine to create a much more serious security problem. The Preview sandbox itself did not fail — the vulnerability appeared because another trusted component accidentally provided a bridge around it.
Comments 0