CVE-2026-5388

The CVSS 9.8 rating for CVE-2026-5388 is analytically misleading, and understanding why matters more than the score itself. The vulnerability affects justhtml versions before 1.15.0, but the critical nuance the severity score obscures is this: the default sanitize=True configuration is largely unaffected, while five distinct bypass categories (URL sanitization flaws, HTML serialization edge cases, Markdown passthrough vectors, custom policy gaps, and preserved dangerous tags) create risk primarily when developers opt out of the safe defaults. The CVSS describes the ceiling of possible harm, not the floor of actual exposure in typical deployments. The URL parsing failures are the most structurally significant. The library accepts encoded javascript: handlers and treats backslash-relative URLs as remote hosts — these aren't simple implementation oversights, they reveal that the sanitization layer sits atop a URL parser with semantic assumptions that weren't designed for security contexts. This architectural layering creates invisible attack surface that will survive incremental patches. The deeper failure is ergonomic, not just technical. This library follows the same arc every major HTML sanitization library has traced: ship safe defaults, encounter friction from legitimate use cases, add helper APIs and escape hatches for power users, watch those escape hatches become default integration patterns in downstream projects, discover subtle bypasses in the escape hatches. The five bypass categories in this CVE are what happens when a library's complexity budget runs out after years of 'just one more helper API' commits. For risk assessment: the real exposure isn't in projects using standard sanitize=True configuration — it's in the integrations that have adopted helper APIs for programmatic DOM construction, or that built custom policies to work around the defaults. These are precisely the usage patterns that tend to persist in production codebases with minimal maintenance attention. The CVE itself notes that most custom-policy issues don't affect the default, which means organizations with standard integrations should verify their actual usage patterns before treating this as a critical-priority item. The downstream blast radius is where this gets genuinely alarming. Every system that consumes justhtml's output and treats it as safe has extended the blast radius by one hop. The 'helper APIs' that bypass sanitization aren't just ergonomic failures — they're the specific mechanisms by which untrusted input skips the serialization boundary entirely and lands in downstream consumers who never expected raw HTML construction from a library they'd classified as safe. The five bypass categories represent five redundant entry vectors, and each represents a potential pathway into systems that built authentication, authorization, or content-security assumptions on the premise that justhtml's output was sanitized. For defenders: prioritize audit of any code paths using helper APIs or custom policies rather than the default configuration. The zombie code problem — pinned dependencies, copied helper functions into internal wrappers, abstractions built on deprecated API surfaces — is where the real risk lives. These patterns don't get re-evaluated when a CVE drops; they get evaluated when something breaks, which is often never. The patch to 1.15.0 is necessary but insufficient if downstream integrations have already internalized bypass patterns that the new version may have changed or removed.

Reviewed through automated stages and approved by a human before publication.