Stop treating ChatGPT share links as inert documents, and audit any team workflow that pastes client data into chats that later get shared. Researchers at Parameter demonstrated that opening a public ChatGPT share was enough to run attacker JavaScript inside the victim's signed-in chatgpt.com session.
The chain, documented by Parameter, abused two unrelated features. ChatGPT's HTML Preview runs user code in a restricted frame, but an interactive graph in the same conversation loaded the MathLive library, which installed a postMessage listener on the main page without checking the sender's origin. The Preview sent a crafted message that replaced a virtual keyboard layout with attacker HTML, then used an iframe srcdoc trick to turn that HTML into JavaScript execution as the victim. The payload could list private conversations, read chats never shared with the attacker, and call authenticated APIs. OpenAI patched it on October 26, 2026 and classified the report P1.
What this means if ChatGPT sits inside your business workflow
If your team sends ChatGPT share links to clients, or embeds HTML Preview output anywhere customer-facing, treat the share surface as untrusted - the specific bug is fixed, but sandbox-escape chains built from legitimate browser features will keep showing up. For sensitive document work I keep processing on scoped API keys instead of the consumer chat UI, which is how a legal document assistant I built handles contracts without ever exposing them to a shareable URL.
Why it matters: Shared chat links are now part of your attack surface - review who can share from your workspace and move anything sensitive onto an API with scoped keys instead of the consumer UI.
Source: Hacker News