HtmlSanitizer CVE-2026-116538

Specific conditions required: (1) the application must use the SanitizeDom(string) API path, and (2) it must serialize/render MORE of the returned document than dom.Body.ChildNodes - i.e. the full document via dom.ToHtml() or the body/html outer HTML - because the vulnerable attributes live on the wrapper elements, not inside the body content; (3) attacker input must include a second <body> or <html> start tag whose attributes (e.g. onload) merge onto the existing wrapper element per HTML5 tree construction; and (4) a victim must render that output (UI:P). Limiting factors that reduce real-world risk: callers that only emit the sanitized body inner HTML are not affected, exploitation is not attacker-controlled on a default serialization path (AT:P), victim interaction is required, and only versions before 9.2.1039 and 10.0 prereleases before 10.0.1037-beta are affected.

All severity signals point to this being a low-priority issue rather than an urgent one. The input CVSS 4.0 base score is 2.3 and the vuln.today Decision label is 'monitor' (not act_now/emergency). The 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N) shows no impact to the vulnerable system itself and only low confidentiality/integrity impact to a subsequent system (the victim's browser), which is consistent with a reflected/stored XSS. The AT:P and UI:P metrics are the key dampeners: exploitation is not fully attacker-controlled on a default path - it depends on how the consuming application uses the output (see exploitation_conditions) and on a victim rendering it. This CVE is NOT in CISA KEV, so it is not confirmed actively exploited. No EPSS score was provided in the input, so exploitation probability cannot be quantified here. A public PoC reference exists (the joshua.hu writeup and the VulnCheck advisory) but the input does not mark it as confirmed working exploit code, so it should be treated as a technical writeup, not a weaponized exploit. Net: a genuine sanitizer-bypass XSS worth patching in a normal maintenance cycle, but low real-world risk - not an emergency.

An application calls HtmlSanitizer.SanitizeDom(string) on attacker-supplied HTML and then renders the serialized full document or the body/html outer HTML rather than only dom.Body.ChildNodes. The attacker submits input containing a second <body> or <html> start tag carrying an event handler (e.g. '<body onload=alert(1)>'); because SanitizeDom never strips attributes on the html/body wrapper elements, the onload handler survives sanitization and executes in a victim's browser when that serialized output is displayed. A public PoC reference exists (joshua.hu / VulnCheck advisory); it is not verified as working exploit code.