CVE-2026-68750 is a high severity (CVSS 7.5) denial of service flaw in html_sanitize_ex. The traversal engine re-flattens the remaining sibling list at every step, so a flat run of sibling elements costs quadratic CPU and memory. Upgrade to 1.4.5 or 1.5.3, and cap the size of HTML you sanitize.
What's affected
The record gives no version range in its text. The Erlang Ecosystem Foundation CNA entry lists affected versions from 0.3.1 before 1.4.5, and from 1.5.0-rc.0 before 1.5.3, with fixes in 1.4.5 and 1.5.3. This is the same range as CVE-2026-68749, so one upgrade closes both.
Severity differs. The NVD record scores it 7.5 (High). The CNA entry gives High 8.2 using CVSS 4.0.
Unlike the CSS issue, this one touches every public entry point. The entry says the traverser sits under all of them, so no particular scrubber or configuration is required, and the input needs only allowed tags. Every user of an affected version is in scope.
How to check if you're exposed
mix deps | grep html_sanitize_ex
grep html_sanitize_ex mix.lock
The lock file shows the resolved version. Check that it is 1.4.5 or later on the 1.4 line, or 1.5.3 or later on the 1.5 line.
Because every entry point is affected, there is no configuration to rule yourself out. Instead, find where user supplied HTML is sanitized and how big it can be:
grep -rn "HtmlSanitizeEx" lib/
For each place, note whether a size limit exists before the call. Comment fields, rich text editors and email rendering are typical sites.
A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.
What to do now
- Upgrade html_sanitize_ex to 1.4.5 on the 1.4 line or 1.5.3 on the 1.5 line, or newer. This also fixes CVE-2026-68749.
- Cap the size of user supplied HTML, and in particular the node count, before sanitizing, as the entry advises.
- Keep the cap small. The entry notes the quadratic growth means a generous cap is not effective.
- Set request timeouts and per client rate limits on endpoints that accept HTML.
- Monitor scheduler utilisation and request latency on those endpoints.
Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.
Why it matters
The weakness is CWE-407, inefficient algorithmic complexity. The list handler recursed on the tail of a sibling list and then flattened the head joined with the already flattened result. Every one of n siblings copied and re-walked everything after it. The flattening is only needed in the rare case where a scrub returns several nodes for one, but the cost was paid every time.
The entry puts it concretely: a 160 KB body of 20,000 sibling elements holds a scheduler for around 1.7 seconds, and cost grows faster than the body. For a library whose job is handling hostile HTML, that is a realistic path to taking a service down. The record does not mark this CVE as known exploited.
Quick check
Does it matter which scrubber I use?
No. The entry says the traversal engine is under every public entry point.
Does one upgrade cover both html_sanitize_ex CVEs?
Yes, both list 1.4.5 and 1.5.3 as fixed, so upgrading to those or later covers CVE-2026-68749 and CVE-2026-68750.
Sources
- https://cna.erlef.org/cves/CVE-2026-68750.html
- Record: NVD entry for CVE-2026-68750 (score 7.5, HIGH)
Last reviewed: 18 October 2026.
