ChatGPT Share-Link Flaw Holds Lessons for Web Developers

A ChatGPT share-link flaw allowed a single public conversation to run attacker code inside the session of a signed-in viewer and read their private chats. Security firm Parameter reported it to OpenAI on October 18, 2026, and OpenAI closed it on October 26. Users need not act, but web developers should study the pattern.

What Parameter found

ChatGPT lets people share a conversation through a public link. Anyone who opens the link can read the chat, and if they are signed in to ChatGPT, the page opens inside their own session.

Researchers at Parameter found a way to build a public conversation that ran attacker-written JavaScript as soon as the link was opened. The code ran as chatgpt.com, so the browser treated it the same way as ChatGPT’s own code. Parameter wrote that its research team “was able to take over anyone’s account simply by sending them a link.”

In testing, Parameter used two separate accounts of its own. The injected code listed the victim account’s recent conversations, opened a private chat that had never been shared, and sent a small excerpt to a server controlled by the researchers as proof. Parameter says the same code could also call ChatGPT’s authenticated APIs on the victim’s behalf, which is why the finding amounts to account takeover.

Parameter’s write-up does not report any attacks on real users. The Hacker News, which covered the research on October 31, 2026, also noted that the proof of concept ran between test accounts and did not target actual users.

How the attack chain worked

The flaw was built from several features that each looked reasonable on their own. The problem appeared when they met inside one public conversation.

The first piece was an interactive graph. When a chat contained a graph, ChatGPT loaded MathLive, an open-source library for displaying and typing math. MathLive installed a message listener on ChatGPT’s main page. That listener accepted data sent through postMessage, the browser function that lets windows and iframes exchange messages.

The second piece was the Preview feature, which renders HTML inside a separate frame with a different origin. That frame was well restricted, and Parameter stresses that the Preview sandbox itself held. Code inside Preview could still send messages to the main page, though.

That is where the chain connected. MathLive’s listener accepted a command to change the virtual keyboard layout without checking the sender’s origin or which window sent it. The layout data could contain raw HTML, which MathLive rendered without sanitizing. The result was an iframe with no sandbox attribute, created by the main page and therefore carrying the chatgpt.com identity.

One barrier remained: the Content Security Policy (CSP), the rule set that decides which script sources a page may run. ChatGPT’s CSP blocked inline scripts but allowed scripts from YouTube. Parameter used YouTube’s oEmbed endpoint in JSONP format. On an error, that endpoint echoed back the requested callback name, so an attacker could shape its output and have it run as a script the CSP considered legitimate.

The first version of the attack needed one click on Preview. Parameter then found that Preview could open automatically when the shared chat loaded, so the victim only had to open the link. Parameter also notes that the full chain survived only when the graph and the Preview sat in the same public conversation. A separate attachment on its own did not work.

The fixes from OpenAI and MathLive

Parameter’s timeline is detailed. The report went in through OpenAI’s bug bounty program on October 18, 2026. On October 21, OpenAI reproduced the issue and raised its severity from P2 to P1. According to The Hacker News, P1 is OpenAI’s most serious category.

The fix arrived in stages. On October 22, one web frontend was fixed while a second was still being updated. On October 23, CSP changes cut off part of the chain. On October 26, OpenAI confirmed that both frontends rejected the messages the attack relied on, closed the report, and paid a $5,000 bounty. Parameter published its technical write-up on October 28, after the fix was live.

ChatGPT users have nothing to install or reset. The Hacker News wrote that users do not need to do anything because the fix sits on OpenAI’s side.

On the library side, MathLive released version 0.111.2 on October 31, 2026, with security changes that address the same pattern. According to the MathLive changelog, virtual keyboard, proxy, and mathfield messages now default to same-origin validation, and cross-origin integrations must list trusted origins explicitly. Keyboard settings sent from another window can only select built-in layouts, while custom HTML layouts must be configured in the window that hosts the keyboard. The changelog does not mention ChatGPT. An earlier release, 0.111.1 on October 9, also fixed a cross-site scripting issue in the shadow option of the \enclose command.

What this means for web development teams

This pattern is not unique to ChatGPT. Many web applications rely on iframes and postMessage: payment widgets in online stores, maps in government portals, equation editors on exam platforms, video players on school sites, and AI chat widgets on service portals. Every listener that accepts data from another window is an entry point, including listeners that a third-party library installs without the team noticing.

These steps fit into a team’s release checklist:

1. Inventory message listeners. Search for addEventListener("message" and onmessage in your own code and in the libraries each page loads. In Chrome DevTools, the Elements panel can show event listeners attached to window. The MDN documentation advises pages that do not expect messages from other sites not to add a listener at all.
2. Verify the sender and the content. MDN says every message should be checked through its origin and, where needed, source properties. Parameter adds that state-changing messages should be matched against both the origin and the exact window that was granted permission. Once the sender is verified, the message format still needs validation.
3. Reject raw HTML from other windows. Cross-window configuration should carry limited values, such as a layout name or a number, rather than HTML fragments that get rendered directly.
4. Sandbox dynamic iframes. When an untrusted party can influence a frame’s content, set the sandbox attribute and grant the fewest permissions possible.
5. Treat CSP as an extra layer. This case shows that one trusted domain with a JSONP endpoint was enough to get past the CSP. Review the allowed domains and remove any that are not truly needed.
6. Test features in combination. Parameter stresses that the flaw came from the interaction of sharing, Preview, a math library, frame creation, and CSP. Security testing should cover scenarios where several features are active at once, especially on pages that can be shared publicly.

Library updates belong in the same work. Teams that use MathLive can check their version with npm ls mathlive and, after updating to 0.111.2, adjust the configuration if they genuinely need cross-origin messages. For other libraries, tracking security releases should be routine, in the same way as server updates. Teams building portals or applications with many embedded components can make these checks part of the design stage in web application development.

For organizations that use ChatGPT at work, the case is also a reminder about public chat links. Anyone can open them, and their safety depends on the platform behind them. Internal rules on what data may go into AI services remain necessary, as discussed in our piece on fake AGENTS.md files and securing AI agents.

Frequently asked questions

Should I change my ChatGPT password?

There is no official advice to do so. The Hacker News wrote that users need not do anything because the fix was made on OpenAI’s side, and Parameter does not report any real-world attacks. Turning on two-factor authentication remains a good habit for any account.

Does this flaw have a CVE number?

The available sources do not mention a CVE number. OpenAI handled the report through its bug bounty program at P1 severity and deployed the fix directly to the ChatGPT web service.

Our site uses MathLive. Are we affected?

It depends on how you use it. The risk arises when a page that loads MathLive also displays content or iframes that someone else can control. Updating to 0.111.2 applies origin checks by default. After that, review any other message listeners on the same page.

Closing thoughts

The ChatGPT share-link flaw has been closed, and users do not need to act. For web developers, the case shows how one message listener without an origin check, inside a third-party library, can open a path into a user’s entire session. If your team wants to review the security of a web application that relies on many embedded components, Merakit’s cybersecurity services can help plan the checks and testing.

Sources

• Parameter: We found a gap at OpenAI (October 28, 2026)
• The Hacker News: A Shared ChatGPT Link Could Run Attacker Code in Your Session and Read Private Chats (October 31, 2026)
• MathLive: CHANGELOG, version 0.111.2 (October 31, 2026)
• MDN Web Docs: Window.postMessage()