ammonia CVE-2026-63430

Exploitation requires an application that has explicitly built a non-default ammonia allowlist enabling ALL of: the <math> tag, the <annotation-xml> tag, and at least one raw-text HTML element (e.g. <xmp>, <noembed>, <noframes>, <style>, <script>-class raw-text parsing), while NOT allowing the 'encoding' attribute on annotation-xml. Under that configuration, ammonia strips the encoding attribute during attribute filtering but fails to re-evaluate annotation-xml's encoding-dependent MathML HTML-integration-point status, so it validates a descendant under one namespace while the browser reparses under another, enabling the namespace transition. Additional conditions: a victim must subsequently render the sanitized output in a browser that applies MathML integration-point reparsing. Key LIMITING factors: the required tags are disabled by default, so applications on stock configuration are NOT affected; exploitation is impossible without the specific permissive allowlist, and impact is limited to client-side script execution (no server-side compromise).

This is a genuine but config-gated vulnerability, not a broad emergency. The vendor CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N, base 6.3/Medium) is internally consistent with the description: network reachable, no privileges, but AT:P (Attack Requirements Present) correctly encodes that exploitation depends on a specific non-default sanitizer configuration, and the impact is confined to subsequent systems (SC:L/SI:L) - i.e. the victim's browser/other users via XSS, with no impact to the ammonia process itself (VC/VI/VA:N). No EPSS score was provided in the input, so probabilistic exploitation likelihood is UNKNOWN. The CVE is NOT listed in CISA KEV in the provided data, so there is no evidence of active in-the-wild exploitation. However, publicly available exploit material does exist: a dedicated researcher writeup (ivan09999.github.io/ammonia-mxss) and a working mXSS payload embedded in the upstream regression test (ns_mathml_3). No SSVC decision record was supplied. The decisive risk driver is the AT:P / configuration precondition - the required tags (math, annotation-xml, a raw-text element) are explicitly NOT enabled by default, so the realistic exposed population is the subset of ammonia users who hand-crafted an allowlist that enables exactly these elements while disabling the encoding attribute. For that narrow population the impact is real stored/mutation XSS; for everyone on defaults, risk is effectively nil. Net: a Medium-severity, low-exploitation-breadth issue that is a priority only for applications with this specific permissive MathML configuration.

An application uses ammonia with a custom allowlist permitting <math>, <annotation-xml>, and a raw-text element (e.g. <xmp>) but not the encoding attribute, to sanitize user-submitted HTML (a comment, message, or profile field). An attacker submits crafted HTML that is valid under ammonia's MathML namespace interpretation but reparses under HTML rules in the browser after the encoding attribute is stripped, smuggling an <img onerror=...> past the filter. A working payload is publicly documented in the researcher writeup and the upstream regression test, so weaponization effort is minimal once the vulnerable configuration is present.