The ChatGPT account takeover vulnerability: how one shared link could read your chats

The Morse teamPublished November 2, 20269 min read

The ChatGPT account takeover vulnerability was a bug, fixed on October 26, 2026, that let a single public ChatGPT share link run an attacker's code inside the signed-in session of whoever opened it. Parameter, the security company that found it, showed the code could list a victim's recent chats, read a private chat that was never shared, and send it to an outside server, and it says the same access allowed "any action on behalf of the victim's ChatGPT account."

We read Parameter's write-up, published October 28, 2026, along with OpenAI's own help pages on code previews, shared links, sessions, and multi-factor authentication, on November 2, 2026. OpenAI hasn't published a statement of its own, so what OpenAI did comes from Parameter's timeline. OpenAI moved quickly. It reproduced the report in three days, raised its severity, and shipped a fix within eight days of the report.

What was the ChatGPT account takeover vulnerability?

It was a cross-site scripting bug: a way to make chatgpt.com run code the attacker wrote, as if it were OpenAI's own. Parameter's write-up, "Do the Math: How We Took Over ChatGPT Accounts" by Mukul Goyal, says the attacker "could create a malicious conversation, publish it using ChatGPT's normal sharing feature, and send the link to another user" (Parameter). When the victim opened it, "the payload executed as chatgpt.com with access to the victim's authenticated web session."

The way in was ChatGPT's code previews. OpenAI's help center says that for supported code blocks you can select Preview to see the result inside ChatGPT, including HTML pages, React components, SVG images, Mermaid diagrams, and Vega charts, and that "code previews and code execution use a sandboxed environment" (OpenAI). Simon Willison notes this is the feature OpenAI used to call Canvas (Simon Willison).

How did one shared link take over a ChatGPT account?

By getting a message out of the sandbox to a part of the page that trusted it. Parameter is clear that the sandbox itself held: "Code inside Preview could not directly read the ChatGPT page. The problem was that another component in the main page was willing to accept its instructions" (Parameter). Here is the chain from the write-up, step by step, in plain terms:

What could the attacker see or do?

Your chat history, at least, and Parameter says more. Its proof called the conversation list (limit=20, newest first), then fetched a chosen private conversation that "was unrelated to the malicious share and had never been shared with the attacker" (Parameter). It then sent part of that conversation to Parameter's own server with an ordinary image request. Parameter sent only "a small piece" on purpose, and adds that the code "had already received the authenticated conversation response and could read its contents."

Beyond chats, the write-up says the code's "reach was not inherently limited to the conversation endpoints used in our proof," because "other data and actions exposed through ChatGPT's authenticated frontend APIs sat inside the same security boundary." It doesn't name memory, connected apps, custom instructions, or account settings, and it doesn't say it tested them. Treat those as within reach but unconfirmed.

Did you have to click anything?

Only the link, in the final version. Parameter "observed two versions of the interaction": in the most stable one, the victim opened the share and clicked ChatGPT's normal Preview button once, and in the later one the preview opened by itself (Parameter). The write-up says the victim "did not need to install an App, join a Project, paste code, or open developer tools. Opening the shared link was the only required action." You also had to be signed in to ChatGPT in that browser, since the attack borrowed your session.

Was anyone's account actually taken over?

There's no public answer. Parameter's write-up describes tests between its own accounts and doesn't report finding real victims. OpenAI hasn't said whether it checked its logs for share links that used the same chain before October 26, and we found no notice to users on its help center.

Is the ChatGPT shared link bug fixed?

Yes. Parameter's timeline, which is the only dated record published, ends with OpenAI confirming the fix on October 26, 2026 (Parameter):

The first link in the chain sat in MathLive, an open-source library that any site can embed. Parameter says MathLive "accepted a state-changing message without proving which frame sent it." As of November 2, 2026, GitHub's advisory database lists three MathLive advisories, the newest from July 29, 2026, and all three are about escaping HTML in math commands, not about the keyboard's messages (GitHub).

Would multi-factor authentication have stopped it?

No, and neither would a strong password. OpenAI's own page describes multi-factor authentication as "an extra verification step when you sign in" (OpenAI). This attack never signed in. It ran in a tab where you were already signed in and used the session that was already there.

It also left nothing in the places you'd look for an intruder. ChatGPT's Active sessions list shows sessions with their device, browser, approximate location, and sign-in time (OpenAI), and Security history records events like sign-ins and password changes (OpenAI). Because the attacker's code ran in your own browser, there was no new device or sign-in for either list to show. Turn on multi-factor authentication anyway. It's the defense against stolen logins, like the more than 100,000 taken by malware from users' own computers in 2023 (Group-IB), which our ChatGPT breach history covers.

What should you do now?

There's nothing to patch on your side, since the fix was on OpenAI's servers. These steps, with the menu paths OpenAI's help center gave on November 2, 2026, close what's still open:

1. Log out everywhere. In ChatGPT, go to Settings, then Security and login, then Active sessions, find Log out of all sessions, select Log out all, and confirm with Log out of all devices. OpenAI says other sessions can take up to 30 minutes to end (OpenAI).
2. Read your security history. Under Settings, Security and login, then Security history, look for sign-ins or setting changes you didn't make. If you find one, OpenAI's steps are to change your password if you use one, log out of all sessions, delete any API keys, and contact OpenAI Support.
3. Clear out your own shared links. Go to Settings, then Data controls, and next to Shared links select Manage. You can delete links one at a time, or open More actions and choose Delete all shared links (OpenAI). OpenAI says links from a personal account can be viewed by "anyone who has a link." Our guide to AI chat share links covers what deleting leaves behind in other apps.
4. Delete chats you no longer need. Anything still saved is what a bug like this can reach. OpenAI says a deleted chat is scheduled "for permanent deletion from its systems within 30 days," unless it was already de-identified or must be kept for security or legal reasons (OpenAI). Our step-by-step for deleting your ChatGPT history has the rest.
5. Open strangers' share links signed out. A private window where you aren't signed in to ChatGPT gives any future bug of this kind no session to borrow.

How Morse keeps your chat history off its servers

The payload's first request asked OpenAI's servers for your 20 most recent conversations, and its second fetched a whole private one. Both worked because ChatGPT keeps every saved chat on OpenAI's servers, one API call away for anything holding your session. Morse's servers don't keep messages or log message content. Your chat history is stored only in your browser, encrypted.

• No chat history on the account. A Morse account holds your sign-in details, plan, balance, and a usage ledger with no content.
• Locked when you sign out. Your stored history takes two keys to unlock: one that never leaves your device, and one our server gives you when you sign in. A copy of the browser data alone can't be read.
• Gone when you clear it. Clearing the browser, losing the device, or deleting the account deletes your chats, and Morse can't recover them, so keep a copy of anything you need.

Then choose a privacy mode for each chat:

• E2EE, for anything no one should read. Your browser checks the secure enclave's proof that it's genuine, then encrypts the message so only that enclave can read it, and our servers relay ciphertext they can't read. The enclaves are run by third-party providers, not by Morse, and the guarantee rests on the enclave hardware and attestation working as designed. E2EE chats come with Pro, at $19 a month.
• Private, for everyday chats with open-weight models and Grok. It's the default. DeepSeek, Kimi, GLM, and Grok run under zero data retention: Morse has zero data retention agreements with its inference, search, and other providers, so they keep nothing. Where a provider confirms that on each reply, Morse checks it and refuses a reply that doesn't.
• Anonymous, to use GPT, Claude, or Gemini without the provider knowing it's you. Our proxy strips your account, email, and IP address before the message goes out under Morse's account. The provider may keep the message for a limited time to check for abuse, under its own policy, so leave out names you'd rather keep to yourself.

Whatever you use, history kept on your own device is only as safe as that device, so lock it and keep software you don't trust off it. Morse doesn't train AI on your chats, sell your data, or show ads.

Try a chat from the Morse home page without an account, or start free and keep your history in your own browser from the first message.