HtmlUnit Neko CVE-2026-104828

Exploitation requires that the consuming application use htmlunit-neko (prior to 5.4.0) as the serialization stage of a parse-transform-serialize flow - specifically an HTML sanitizer, content filter, or normalizer that relies on HTMLWriterFilter to re-emit parsed HTML - AND that the serialized output is subsequently rendered by a browser. The attacker must be able to supply HTML in which entity-encoded markup appears inside the escapable raw-text elements TEXTAREA or TITLE; the parser decodes those entities and printCharacters() writes them back as raw markup. Limiting factors that reduce real-world risk: the flaw is inert if htmlunit-neko is used only for parsing/inspection and not for producing sanitized output, if a different serializer is used, or if output is never rendered in a browser; it is also limited to deployments running a version before 5.4.0.

This is a CWE-79 cross-site scripting sanitizer-bypass in the htmlunit-neko library, scored CVSS 7.2 (High) with vector AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N - network reachable, low complexity, no privileges, no user interaction, and a scope change reflecting that injected markup executes in a separate component (the victim's browser). No EPSS probability, CISA KEV entry, or public POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the 7.2 is driven largely by the scope change rather than by observed in-the-wild activity. The practical risk is strongly conditional: this is not a flaw that triggers against htmlunit-neko in isolation but only when the library is used as the serialization stage of a parse-transform-serialize sanitizer or content-filter pipeline whose output is subsequently rendered by a browser. Teams using htmlunit-neko purely for parsing/testing (its HtmlUnit headless-browser lineage) and not for security sanitization face materially lower risk. Overall this is a legitimate 'patch it' issue for anyone relying on htmlunit-neko to sanitize untrusted HTML, but absent EPSS/KEV/POC signals it is not an emergency drop-everything item for most deployments. Note the provided vector asserts UI:N, which is reasonable for a stored/persistent XSS where any later viewer triggers execution, but differs from classic reflected-XSS UI:R assumptions - verify against your rendering model.

An attacker submits content containing entity-encoded HTML (e.g. '<script>...') placed inside a TITLE or TEXTAREA element to an application that uses htmlunit-neko to sanitize or normalize HTML. During the parse-and-serialize round trip the parser decodes the entity references and HTMLWriterFilter re-emits them as raw markup, so the supposedly sanitized output contains live executable markup that runs when a victim later renders the page. No public exploit identified at time of analysis, though the fix commit and canonical-HTML test fixtures publicly illustrate the decoding-to-raw-markup behavior.