The CVSS 6.1 assigned to this HTML sanitization bypass in html_sanitize_ex is technically accurate but practically misleading—and the gap between those two statements is what matters for your deployment.
The vulnerability is real: the library's URI guard for <object data> uses case-sensitive prefix matching against "javascript:", allowing bypasses like "JavaScript:" or "JAVASCRIPT:". It also fails to block data: URIs and same-origin paths. These are genuine sanitization flaws.
But the vendor's own characterization is the real problem. They've explicitly enumerated the preconditions required for exploitation—JavaScript doesn't execute through <object data>, data: URIs produce opaque origins, and same-origin script delivery requires the attacker to already control same-origin content. This framing shifts the security decision onto every downstream consumer who uses this library, which is exactly who the library exists to protect.
Here's why this matters practically: applications using html_sanitize_ex almost certainly built on the assumption that it handles security complexity for them. They may have reduced input validation elsewhere because they trusted the sanitizer, or logged "sanitized" output as implicitly safe. The bypass doesn't just fail one layer—it invalidates assumptions that powered other defensive layers. The CVSS asks whether this can be exploited in a specific configuration; it should also ask how many systems are operating under false assumptions because they trusted this tool.
The same-origin requirement that makes this "hard to exploit" is also common in practice: user-uploaded content, markdown renderers, template injection contexts, and CMS platforms with file upload features are all deployment patterns that satisfy it. What the vendor frames as defense-in-depth is actually a precondition chain that maps directly onto real-world application architectures.
The temporal dimension compounds this. The bypass existed across versions 0.3.1 through 1.5.3—a multi-year exposure window during which every Elixir application pulling this dependency carried this gap in production, most with no signal that their sanitizer had known URI guard limitations. The CVE-to-fix publication lag compounds with dependency update lag, creating compounding exposure measured in deployments rather than code diffs.
For defenders: treat this as higher-severity than the CVSS suggests if your application serves user-controlled content and satisfies the same-origin condition. Don't reduce input validation because you use this sanitizer. Review whether your deployment pattern—file uploads, content injection points, markdown rendering—creates the precondition chain the vendor describes. The library's documentation of "acceptable limitations" is now adversarial reconnaissance material: it tells exactly where the bypass chains and which applications are vulnerable.