Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
XSS via user-supplied LaTeX requires low privileges to inject; no availability impact path exists for a text-rendering XSS.
Primary rating from Vendor (https://github.com/arnog/mathlive).
CVSS VectorVendor: https://github.com/arnog/mathlive
Lifecycle Timeline
2Blast Radius
ecosystem impact- 64 npm packages depend on mathlive (22 direct, 42 indirect)
Ecosystem-wide dependent count for version 0.110.0.
DescriptionCVE.org
Summary
Despite the 0.104.0 patch escaping attribute-bearing constructs (\htmlData, \href), text-content reflection was missed. The \text{}, \mbox{} commands accept arbitrary characters in their body and emit them raw and unescaped into both the HTML markup and the MathML output, leading to XSS.
Details
Box.toMarkup at src/core/box.ts:356 concatenates this.value into the rendered span without HTML-escaping. In text mode any literal character (<, >, &, ") is wrapped into a TextAtom whose value is the raw codepoint and lands in the markup unchanged. The MathML serializer at src/formats/atom-to-math-ml.ts is independently broken: xmlEscape deliberately omits the & rule, and scanText, case 'text', and the mode === 'text' early return all emit atom.value raw.
Both outputs flow into innerHTML sinks via the public API. <math-span> / <math-div> (src/public/math-static-elements.ts:331,407) bypass MathfieldElement.createHTML entirely. The editor and SSR paths route through createHTML, but its default value is the identity function (src/public/mathfield-element.ts:789).
PoC
- Go to https://mathlive.io/mathfield/demo/
- open DevTools console and paste:
const s = document.createElement('math-span');
s.style.display = 'block';
s.textContent = '\\text{<img src=x onerror=alert(1)>}';
document.body.appendChild(s);
s.scrollIntoView();Equivalent payloads: \mbox{<img src=x onerror=alert(1)>}
or
import { convertLatexToMarkup } from 'mathlive';
document.body.innerHTML = convertLatexToMarkup('\\text{<img src=x onerror=alert(1)>}');Impact
MathLive users who render untrusted mathematical expressions can encounter malicious input that runs arbitrary JavaScript.
AnalysisAI
Cross-site scripting in MathLive (npm/mathlive <= 0.109.2) allows arbitrary JavaScript execution when applications render untrusted LaTeX containing \text{} or \mbox{} commands. The vulnerability bypassed a prior partial fix in version 0.104.0 that addressed attribute-bearing constructs but left text-content reflection in both the HTML (Box.toMarkup) and MathML (atom-to-math-ml.ts) rendering paths unescaped, with both outputs flowing into innerHTML sinks. A publicly available proof-of-concept exploit is documented in the GitHub advisory; no active exploitation has been confirmed in CISA KEV at time of analysis.
Technical ContextAI
MathLive is a JavaScript/TypeScript library (pkg:npm/mathlive) for rendering and editing mathematical expressions in LaTeX. The root cause is CWE-116 (Improper Encoding or Escaping of Output). In the HTML rendering path, Box.toMarkup at src/core/box.ts:356 interpolated this.value raw into a <span> element without any HTML entity encoding - characters such as <, >, and & from \text{} or \mbox{} arguments were stored as TextAtom.value and concatenated directly into markup. In the MathML path, the xmlEscape helper in src/formats/atom-to-math-ml.ts deliberately omitted the & replacement rule, and scanText plus text-mode branches emitted atom.value raw into <mtext> elements. Both paths feed into innerHTML assignment sites in the public API. Critically, the static custom elements <math-span> and <math-div> (src/public/math-static-elements.ts:331,407) bypass the MathfieldElement.createHTML sanitization hook entirely, and that hook defaults to the identity function (src/public/mathfield-element.ts:789), providing no protection even on the paths that reach it.
RemediationAI
Upgrade MathLive to version 0.110.0 or later, which introduces a dedicated escapeText() function in src/core/box.ts that encodes &, <, and > in HTML element content, and fixes xmlEscape in src/formats/atom-to-math-ml.ts to include & escaping across all text-mode serialization paths including scanText, <mtext>, <mi>, and delimiter elements. The fix commit is https://github.com/arnog/mathlive/commit/5fe1c46153883f9ec0249a5c8c34e64aaae9cfb8. If immediate upgrade is not feasible, the most targeted compensating control is to validate or sanitize LaTeX input before passing it to any MathLive rendering function, specifically rejecting or stripping raw HTML characters (<, >, &, ") within \text{} and \mbox{} argument bodies - be aware this may break legitimate use of typographic characters. Applications can configure MathfieldElement.createHTML to invoke a sanitizer such as DOMPurify for editor and SSR paths, but this does not protect <math-span> or <math-div> which bypass that hook entirely. Restricting LaTeX input to authenticated trusted users reduces exposure but is not a technical remediation.
Same weakness CWE-116 – Improper Encoding or Escaping of Output
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-50421
GHSA-fm7p-gw32-828p