· via dev.to (home feed)
MathLive 0.111.2 adds origin checks after ChatGPT share-link code execution chain
MathLive's postMessage listener accepted messages from any origin, which let a shared ChatGPT link run attacker code as chatgpt.com. Version 0.111.2 defaults to same-origin validation.

MathLive now validates message origins by default
MathLive, an open-source library for math input fields, shipped version 0.111.2 on October 31 with a changelog containing only a Security section. Its headline change: virtual keyboard, proxy and mathfield messages now default to same-origin validation. The release notes make no mention of ChatGPT, OpenAI or the security firm Parameter, carry no CVE identifier, and Parameter's writeup does not say it contacted MathLive's maintainers, so the link between the two events is inference rather than record — though the timing follows a disclosure in which MathLive was the first link in a code-execution chain against chatgpt.com.
How a share link became code execution
According to Parameter's writeup, published October 28 and recounted in a dev.to post, the firm built an attack where the only user action — in its final version — was opening a link to a shared ChatGPT conversation. An earlier, more stable variant required one click on the preview. The chain worked like this:
- An attacker publishes an ordinary conversation containing an interactive graph and an HTML code block. The graph loads MathLive, which registers a message listener on the main ChatGPT page.
- The HTML preview runs in a sandboxed iframe on a separate origin. It cannot read the parent page, but it can call postMessage on it, and it emits messages of type
mathlive#virtual-keyboard-message. - MathLive's controller used an origin policy of 'none' — the default its API reference documents — so it accepted those messages from any origin and did not require them to come from a window it had approved.
- The keyboard layout carried in the message was markup, inserted into the page through innerHTML. Parameter found that the createHTML step acted as a pass-through wrapper rather than a sanitizer.
- That markup created an iframe with srcdoc and no sandbox attribute. Because the main page created it, the frame inherited the chatgpt.com identity.
- ChatGPT's Content Security Policy blocked inline scripts but allowed www.youtube.com, and a JSONP-style callback parameter on YouTube's oEmbed endpoint supplied the script.
With script execution on chatgpt.com, the researchers enumerated the victim's recent conversations, fetched a private one through ChatGPT's authenticated API and sent part of it to a server they controlled. They demonstrated the conversation read only, but Parameter assessed the access as equivalent to full control of the victim's account.
Timeline of the fix
Parameter reported the issue through OpenAI's bug bounty on October 18. OpenAI reproduced it on October 21 and raised severity from P2 to P1. Between October 22 and 23, one frontend was patched and CSP changes blocked part of the chain. On October 26, eight days after the report, both frontends rejected the messages and OpenAI paid a $5,000 bounty; no user action was needed. Parameter reports no real-world exploitation, and its proof ran between its own separate accounts rather than against real users.
What 0.111.2 changes
Beyond the same-origin default, the release closes the other doors the chain used. Cross-window keyboard settings can no longer supply custom layouts or keycap overrides, even with origin validation disabled; custom HTML layouts are now configured in the keyboard's own host window. Messages that change state are tied to the window of the mathfield they belong to. Same-origin checks no longer treat two opaque 'null' origins as equal, nor accept a wildcard sender origin. Integrations that span origins now have to declare which peer origins they trust.
Applications shipping MathLive should check their version with npm ls mathlive and upgrade to 0.111.2 or later. One caveat: the API reference still lists 'none' as the default for originValidator, so integrations should set the policy explicitly, for example mathVirtualKeyboard.originValidator = 'same-origin', rather than relying on either version's default. For keyboards that genuinely talk across origins, the validator can be a function that allows only specific trusted origins.
The broader audit applies to any page: find every message listener, check both event.origin and event.source before acting, and never accept raw HTML across windows as configuration.
Why it matters
Two lessons stand out. First, MathLive's documented default was to accept postMessage input from any origin, which means every integration that did not opt into validation inherited the hole; a single unsafe listener at the library level became a broad attack surface across every site embedding it. Second, the chain shows how AI products that render untrusted output — shared chats, model-written HTML, preview panes — alongside third-party widgets create seams where individually reasonable decisions compose into full account takeover. Parameter's conclusion is that CSP helps as defense in depth but cannot redeem an unsafe rendering path, as the YouTube oEmbed callback demonstrated. The general fix is unglamorous: validate who sent a message before trusting what it says.
- #security
- #javascript
- #open-source
- #chatgpt
- #web