Do the math: How we took over ChatGPT accounts
- ID
- 41620
- Status
- summarized
- Published
- 31 Oct 2026, 6:30 PM
- Fetched
- 01 Nov 2026, 6:09 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://www.parameter.ai/labs/we-found-a-gap-at-openai
- Source URL
- https://hnrss.org/best
Summary
- Score
- 8.5
- Created
- 01 Nov 2026, 6:10 AM
- Tags
- Audience
- developersvibe_codersai_agent_userssaas_founders
What happened
ParameterLabs found that a malicious public ChatGPT share could execute attacker-controlled JavaScript inside the signed-in chatgpt.com session of anyone who opened the link. The chain abused ChatGPT's HTML Preview crossing into the main page plus a MathLive postMessage listener, letting the payload enumerate conversations, read a private never-shared conversation, exfiltrate data, and call authenticated ChatGPT APIs as the victim. OpenAI fixed it on October 26, 2026 and classified the report as P1.
Why it matters
Treat public ChatGPT share links as untrusted input, and if you build previews, embeds, or iframes, do not rely on sandboxing alone: audit parent-page postMessage listeners for origin/source checks. The concrete lesson is that a harmless-looking HTML Preview plus a third-party library listener was enough to cross a trust boundary without the victim installing anything or pasting code.
Discussion angle
What preview, embed, or share features in your own product cross a trust boundary, and how would you test whether a third-party library's postMessage listener can be triggered from untrusted content?