LazyHTML EUVD-2026-86828

Exploitation requires a consuming application that (1) uses lazy_html 0.1.0-0.1.12 to parse attacker-supplied HTML, (2) filters the resulting document or tree with an element/attribute allowlist, and (3) serializes it back to HTML for display to a victim. The specific technical trigger is a style or script element placed inside SVG or MathML foreign content (e.g., <svg><style>), where character references are decoded on parse but the element is serialized as an HTML raw-text element, emitting its text unescaped. Limiting factors: the payload must survive as a plain text node (which is precisely why filters miss it), a victim must view the rendered output (UI:P/passive), and applications that do not run untrusted HTML through a lazy_html parse-filter-serialize pipeline are unaffected. lazy_html on its own - without such a downstream serialization-for-display flow - is not exploitable.

This is a genuinely low real-world risk despite being a sanitizer-bypass XSS. The CVSS 4.0 base score is only 2.3 (vendor/CNA-assigned via EEF), and the vector AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N tells a coherent story: network-reachable, no privileges, but an Attack Requirement (AT:P) and passive User Interaction (UI:P) both apply, and impact is confined to the subsequent (victim browser) system at Low integrity/confidentiality with no availability effect. The AT:P is well-justified - exploitation only matters when a consuming application specifically uses lazy_html to parse untrusted HTML, sanitize/filter it, and re-serialize it for display; lazy_html is a parsing library, not a server, so it has no attack surface on its own. No EPSS score, no CISA KEV listing, and no public PoC are present in the intelligence provided - consistent with a low-severity library flaw disclosed responsibly through a GitHub Security Advisory (GHSA-8rqp-v692-v82q) with a patch already available. There is no signal conflict: every source (low CVSS, library-only footprint, absence of exploitation data) points the same direction. The one nuance defenders should note is that the true impact depends entirely on the downstream application - in a filtering pipeline that trusts lazy_html's serialized output as 'clean', this mutation XSS fully defeats element/attribute allowlist filters because the payload lives in a text node no filter inspects, which could elevate practical impact above the raw 2.3 in a specific vulnerable consumer.

An Elixir/Phoenix application accepts user-submitted HTML (e.g., a comment or rich-text field), parses it with lazy_html, applies an element/attribute allowlist filter, and serializes the tree back to HTML for display to other users. An attacker submits HTML containing <svg><style>&lt;/style&gt;&lt;img src=x onerror=...&gt;</style></svg>; the encoded markup passes the filter as an inert text node but, on the serialize round-trip, the style element is emitted as raw text, so the browser re-parses it as a live <img onerror> and executes attacker script in the victim's session. No public PoC is identified in the provided data, though the advisory describes the mechanism precisely.