What happened in the ChatGPT share link vulnerability?
Security researchers at Parameter found a way to take over a ChatGPT account with a single shared link. The link looked like a normal public conversation, yet opening it could run attacker-controlled JavaScript inside the victim's signed-in session.
ChatGPT's share feature turns a conversation into a public URL that anyone can open. That is convenient for collaboration and support. It also means the payload arrives on a trusted domain, with no attachment to warn the recipient.
Parameter reported the flaw to OpenAI on October 18, 2026. OpenAI reproduced it three days later and raised the severity from P2 to P1, its most serious category. The company fixed both versions of the ChatGPT web frontend on October 26.
The research moved quickly: Parameter confirmed the message path against production code on October 13. It had arbitrary JavaScript through the normal interface on October 14. Cross-account delivery worked on October 16, and the automatic Preview variant worked the next day.
Public shares are designed to travel. Parameter says an attacker could send the link by email, chat, support ticket or social post. That is exactly how an ordinary shared conversation reaches a colleague or a stranger.
Parameter published its technical writeup on October 28. The Hacker News, Ostorlab and Aviatrix Threat Research Center covered the disclosure on October 31. OpenAI paid a total bounty of $5,000 for the report.
The flaw did not require a password, a malicious app or a fake login page. The victim only had to open a chatgpt.com share URL. In the most reliable version, they also clicked the Preview button once. A later variant opened Preview automatically, so the click disappeared.
How did a shared link run code inside a signed-in session?
The chain depended on two ordinary ChatGPT features: an interactive graph and an HTML Preview. Either one alone was harmless. Combined in a single public conversation, they crossed a security boundary.
ChatGPT renders an HTML code block inside a Preview frame on a separate web address. That sandbox held: code in the Preview could not read the main ChatGPT page. The graph, however, loaded MathLive, a math-input web component, into the main page.
MathLive installed a listener for virtual-keyboard messages. Parameter found that the listener accepted state-changing messages without checking which frame sent them. It also allowed raw HTML as keyboard-layout data.
The Preview sent two messages from inside its sandbox. The first replaced the keyboard layout with attacker HTML. The second told MathLive to display the keyboard, which wrote that HTML into the main ChatGPT page.
One early version failed for a mundane reason. When Parameter exported the conversation as a public share, the attachment survived but the graph did not. Without the graph, MathLive never loaded and nothing listened for the messages.
The breakthrough was putting both pieces into one ordinary public conversation. The resulting share link preserved the complete chain for the next visitor. The graph and Preview still loaded independently, so the payload could fire before MathLive was ready. The final carrier retried the two messages for a limited period.
Parameter reproduced the automatic path three times in a separate account, including after a hard refresh. The alert appeared after roughly 4.5 seconds. The final callback was 5,533 characters, and the finished iframe markup was 7,390.
- •The HTML Preview ran on a separate, sandboxed web address.
- •A graph in the same conversation loaded MathLive in the main page.
- •MathLive's controller accepted keyboard messages from any origin.
- •The layout field accepted raw HTML and was written through innerHTML.
- •A helper called createHTML marked the string as trusted, not sanitized.
- •The injected HTML created an unsandboxed frame that inherited chatgpt.com.
Why didn't the sandbox and CSP stop the attack?
The Preview sandbox worked as designed. The failure came from a trusted component in the main page that was willing to act on instructions from an untrusted frame.
Parameter lists three design choices that lined up. MathLive accepted a state-changing message without proving the sender. The message format allowed raw HTML. The resulting HTML could create an unsandboxed document with the site's identity.
A script tag inserted through innerHTML stays inert. A fresh document created with srcdoc is parsed normally. Because the main page created the frame, the browser treated that document as part of chatgpt.com.
Content Security Policy was a backup control, not the root cause. It blocked inline JavaScript, which is why the attackers needed a third-party script host. ChatGPT's allowlist for YouTube supplied one.
Parameter abused YouTube's oEmbed endpoint, which accepted a JSONP-style callback. The endpoint returned the callback before its validation error. Ending the callback with ;void made the appended error object harmless. Google also rewrote angle brackets in the callback, so the payload used classic function syntax.
The oEmbed response came back with a JavaScript content type and nosniff. The researchers did not observe a Cross-Origin-Resource-Policy header. Those details made an ordinary media endpoint usable as a script source on chatgpt.com.
The createHTML helper also gave false comfort. It looked like a sanitizer but behaved as an identity policy. It labeled attacker HTML as trusted and passed it through unchanged.
Blocking YouTube alone would not have closed the hole. Parameter says an untrusted Preview could still push HTML into the main site through the MathLive listener. The third-party script endpoint was the last step, not the root cause.
OpenAI raised the severity on October 21. One frontend was fixed by October 22, and CSP changes on October 23 blocked part of the chain. The second frontend needed until October 26. Both then rejected the cross-frame MathLive messages the report relied on.
Who was affected, and is ChatGPT safe now?
Anyone who opened a crafted public ChatGPT share before October 26 was potentially exposed. Ostorlab notes that no app install, workspace invitation or attacker-controlled login was needed.
The published reports describe a flaw in the web frontend. They do not describe an attack path through the ChatGPT mobile apps.
The reports do not say when the chain first became possible. They describe exposure only from the crafted shares to the October 26 fix. That leaves the true start of the exposure window unknown.
There is no reported evidence of real-world exploitation; Parameter ran its private-chat proof between accounts it controlled. The Hacker News says the researchers do not report any real-world use.
In the researchers' test, the payload parsed the parent page's bootstrap data for a session token and account ID. It sent both as Authorization and ChatGPT-Account-ID headers. It then listed recent conversations and opened a private chat that had never been shared.
The code used ChatGPT's own conversation endpoints, 20 chats at a time. It fetched two turns from the chosen conversation. A fallback route ran only if the detail request returned 403, 404 or 405. The proof sent a small selected value to an image URL on a researcher server.
ChatGPT users do not need to install or reset anything. The fix was deployed by OpenAI, and a crafted share opened today should not run the payload.
Account holders can still reduce exposure in general. Treat unexpected shared chats as untrusted links. Review active sessions if a share behaved oddly. Check the shared-link settings on conversations that contain sensitive material.
What does the MathLive 0.111.2 update change?
MathLive is an open-source web component for math input, published on npm. ChatGPT used it for the interactive graph that installed the vulnerable listener.
The library shipped version 0.111.2 on October 31, 2026, five days after OpenAI's fix. Its changelog describes same-origin validation for virtual-keyboard, proxy and mathfield messages by default.
Cross-origin integrations must now allow trusted peer origins explicitly. Cross-window keyboard settings can select built-in layouts but cannot supply custom layouts or keycap overrides. State-changing messages are bound to the connected mathfield window. The library also stopped treating unrelated opaque origins or a wildcard as a valid sender.
The change reaches beyond the ChatGPT chain, so any site that relied on permissive cross-frame keyboard messages will need explicit configuration. That is the right default, but it is also the kind of upgrade that can break a working integration.
The changelog entry does not name ChatGPT or Parameter, but it does describe the same validation gap that the exploit relied on. npm published 0.111.2 at 20:38 UTC on October 31, and 0.111.4 followed at 21:10 UTC.
MathLive had a separate security problem earlier in October. Version 0.111.1, published October 9, fixed several XSS issues in LaTeX rendering. The GitHub advisory covers attribute injection through the \enclose shadow option and through \htmlData and \href values.
Advisory GHSA-j6jx-5m69-9fcr carries a CVSS score of 7.2. It lists versions through 0.111.0 as affected and 0.111.1 as patched. It is not the ChatGPT chain, but it shows the same library had two unrelated security issues in one month.
Ostorlab warned that version inventories were confusing. The npm registry and GitHub's Releases page disagreed about the latest version. That makes it hard to know which build contains the hardening. Sites that embed MathLive should upgrade and test their cross-origin keyboard integrations.
Was $5,000 a fair bug bounty for a P1 account takeover?
Parameter's timeline shows a fast vendor response. The report went in on October 18, OpenAI reproduced it on October 21, and the fix landed on October 26. The total award was $5,000.
By impact, the bug sat at the top of the web risk scale. It crossed user accounts, bypassed the need for credentials, and reached private conversations. OpenAI classified it P1, which The Hacker News describes as its most serious category.
A P1 label signals urgency inside OpenAI, not the size of the award. The public timeline shows eight days from report to confirmed fix.
The published record does not include a separate payment for the private-chat proof or a public severity-to-payout table for this case. Parameter lists one total. The Hacker News links OpenAI's program to its Bugcrowd engagement page.
Bounty pricing is a policy choice, not a measurement of harm. A modest award can still be rational for a company that fixes quickly. It can also weaken the incentive to report quietly instead of selling elsewhere.
A ChatGPT account can hold long-running conversations and connected app data. That makes a cross-account read primitive valuable, even when the payout is small.
The more concrete gap is transparency. No CVE was assigned, and the coverage reviewed for this article does not cite a public OpenAI technical advisory for the chain. Defenders are working from the researcher writeup and secondary coverage.
Parameter published its writeup ten days after reporting, once the fix was confirmed. That is a normal coordinated-disclosure rhythm. It also means the public learned about the chain only after the window to exploit it had closed.
Parameter's own summary of the impact is blunt. The researchers wrote that they could perform any action on behalf of the victim's ChatGPT account.
What should developers and security teams watch next?
The immediate technical lessons are portable. A postMessage receiver should check both the sender's origin and the exact window that was granted permission. Cross-window settings should never carry raw HTML.
Frames created from untrusted content should stay sandboxed. CSP should remain a backup control, not the only barrier after attacker HTML reaches a trusted page.
Teams should also inventory third-party libraries that install global listeners. A math keyboard, charting package or rich-text editor can widen the attack surface of a page that looks self-contained.
Security teams can test for the pattern. Send a state-changing postMessage from a sandboxed frame to a page that loads a third-party widget. Check whether the receiver validates both origin and source before it acts.
The most useful audit question is simple. Which parts of a page can be influenced by another user, and which of those parts can reach a privileged listener? Share links, previews and embedded artifacts all qualify.
AI chat products deserve particular scrutiny. They hold long-lived, sensitive conversations and encourage users to share links. That combination makes same-origin code execution unusually valuable to an attacker.
The MathLive case also argues for reviewing dependency updates closely. The upstream fix changed defaults, which is the kind of change that can break integrations or pass unnoticed.
The next signals to watch are a CVE or vendor advisory for the ChatGPT chain. Wider adoption of MathLive 0.111.2 or later also matters. Similar reports involving other share or preview features would too.
For now, the confirmed facts are narrow: one chain, one vendor, one library, fixed in October. The broader pattern is the part likely to repeat.