# A shared ChatGPT link could read private conversations

Parameter Security says a public conversation could cross ChatGPT's Preview sandbox, run JavaScript as chatgpt.com and call authenticated conversation APIs.[1] OpenAI fixed the reported chain on October 26, according to the researchers.[1]

Parameter Security reported a cross-feature exploit that joined a ChatGPT graph, an HTML Preview, MathLive's message listener, an unsandboxed srcdoc frame and an allowed YouTube script endpoint.[1] The researchers say a victim only had to open a crafted public share in the automatic version of the attack. Their proof listed private conversations, retrieved content from an unrelated private chat and sent a selected value to a controlled server.[1] OpenAI reproduced the JavaScript and private-conversation proof, raised the report to P1 and confirmed that two web frontends rejected the reported messages on October 26, according to Parameter's timeline.[1] OpenAI has not published its own incident statement, so the severity, bounty and remediation details remain researcher-reported.[1][2]

## What the researchers demonstrated

[Parameter Security's technical report [1]](https://www.parameter.ai/labs/we-found-a-gap-at-openai) says a malicious public ChatGPT share could execute attacker-chosen JavaScript inside another user's signed-in chatgpt.com session. The most stable version required the victim to press ChatGPT's normal Preview button, while a later version opened the preview automatically after the share loaded.

The proof used authenticated frontend APIs to list the victim's conversations and retrieve messages from a private conversation that the victim had never shared with the attacker.[1] The researchers then sent a small selected value to a server they controlled to establish that data could leave the session.

The report does not say that the researchers exploited users outside controlled test accounts, and it does not establish that another attacker used the chain before the fix.[1]

## How five features formed one exploit chain

ChatGPT's Preview ran user-controlled HTML in a separate origin, so Preview code could not directly inspect the parent document.[1] A graph on the same shared conversation loaded MathLive in the main ChatGPT page and installed a postMessage receiver.

Parameter found that the receiver accepted a virtual-keyboard setting from an untrusted frame and allowed raw HTML in the keyboard layout.[1] The main page inserted that HTML, which created an unsandboxed srcdoc iframe with the chatgpt.com origin.

ChatGPT's Content Security Policy blocked inline JavaScript, but it allowed scripts from YouTube. The researchers used YouTube's oEmbed callback response as an allowed script, which completed JavaScript execution inside the inherited origin.[1]

The report identifies the unauthenticated cross-frame message and unsafe HTML rendering as the main failures. Blocking the YouTube endpoint alone would have removed one execution route while leaving attacker-controlled HTML in a privileged page.[1]

## What OpenAI fixed and what remains unconfirmed

Parameter says OpenAI reproduced the JavaScript execution and private-conversation proof, raised the issue from P2 to P1 and updated two versions of the ChatGPT web frontend.[1] On October 26, OpenAI reportedly confirmed that both versions rejected the cross-frame MathLive messages used in the report.

[Ostorlab's independent analysis [2]](https://blog.ostorlab.co/chatgpt-shared-link-account-takeover.html) summarizes the same cross-frame trust failure and exploit chain. It does not provide an independent reproduction against the fixed production service.

OpenAI has not published a public advisory for this report. The P1 classification, $5,000 bounty, affected frontend versions and fix confirmation come from Parameter's account.[1][2] No public source cited here gives an affected-user count or evidence of exploitation outside the research.

## Response checklist for ChatGPT users and workspace owners

- Treat the reported link chain as fixed. If your risk profile warrants a retrospective check, choose a review window from your own retained browser, identity-provider and workspace records. Parameter confirmed the first working path on October 13, but that date does not establish when the vulnerable code first reached users.[1]
- Ask users whether they opened unexpected ChatGPT share links during that window, especially links that displayed a graph and an HTML Preview. A remembered link alone does not prove compromise.
- Review active sessions, connected applications, changed security settings and unusual conversation access. Revoke sessions when evidence or policy supports that action.
- Use phishing-resistant sign-in and strong recovery controls. These controls do not stop same-origin code in an already authenticated tab, but they reduce separate account-access risks.
- Do not circulate proof-of-concept payloads through live accounts. Preserve suspicious URLs and timestamps for your security team without reopening them in an authenticated production browser.
- Contact OpenAI through an established support or account channel if logs show suspicious access or your organization needs confirmation beyond the public researcher report.

## Engineering lessons for embedded AI previews

- Authenticate both event.origin and event.source before a postMessage receiver accepts state-changing instructions.
- Define message schemas narrowly and reject HTML, script URLs and nested documents where plain data is sufficient.
- Keep dynamically created documents sandboxed when an untrusted frame can influence their content.
- Treat Content Security Policy as a backup control. Review allowed JSONP, callback and script endpoints as executable dependencies.
- Test complete feature combinations, including public sharing, graphs, previews, attachments and signed-in APIs.
- Measure impact with the permissions of the active session. An alert proves code execution, but authenticated reads and writes establish the real boundary.

## Limitations and open questions

- The detailed timeline and remediation status come from Parameter Security, the reporting party.[1]
- OpenAI has not published a public advisory confirming the P1 rating, bounty or exact code changes.
- The report demonstrates capability in controlled accounts but does not establish exploitation against other users.
- Public sources do not identify how many people opened crafted shares before October 26.
- The fix rejected the reported MathLive messages, but public sources do not provide the complete production patch or a third-party post-fix audit.

## Frequently asked questions

- Is the reported exploit still active? Parameter marks it fixed and says OpenAI confirmed both web frontends rejected the reported messages on October 26.[1] No cited source provides an independent post-fix audit.
- Did opening any ChatGPT share compromise an account? No. The attacker had to prepare a specific conversation containing the graph and Preview chain.[1]
- Did the attack require a malicious ChatGPT App? The final public-share version did not require the victim to install an App or join a Project.[1]
- Could it read private chats? Parameter's proof retrieved content from a separate private conversation through authenticated frontend APIs.[1]
- Would MFA stop this chain? The exploit ran inside an already authenticated browser session, so login MFA did not address the reported same-origin execution path.
- Was real-world abuse confirmed? The cited reports do not provide evidence that another attacker exploited users before the fix.[1][2]

## Sources

- [[1] Parameter Security: Do the Math, How We Took Over ChatGPT Accounts](https://www.parameter.ai/labs/we-found-a-gap-at-openai)
- [[2] Ostorlab: ChatGPT shared-link account takeover analysis](https://blog.ostorlab.co/chatgpt-shared-link-account-takeover.html)