CVE-2026-68749 is a high severity (CVSS 7.5) denial of service flaw in html_sanitize_ex, an Elixir HTML sanitizer. A long CSS declaration makes the CSS scrubber's regular expression use CPU quadratically. Upgrade to 1.4.5 or 1.5.3, or choose a scrubber that does not process CSS.
What's affected
The record names html_sanitize_ex but gives no version range in its text. The Erlang Ecosystem Foundation CNA entry I retrieved lists affected versions from 0.3.1 before 1.4.5, and from 1.5.0-rc.0 before 1.5.3. Fixed versions are 1.4.5 and 1.5.3.
Severity differs. The NVD record scores it 7.5 (High). The CNA entry gives High 8.2 using CVSS 4.0.
Not every use is affected. The CNA entry says only html5/1, and custom scrubbers built with the html5 extension, route input into the CSS scrubber through style element bodies and style attributes. The other built in scrubbers, basic_html, markdown_html and strip_tags, do not reach it.
The impact is CPU exhaustion only, in the entry's words. Nothing is read, modified or disclosed.
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.
Then check which scrubber your code calls:
grep -rn "HtmlSanitizeEx\." lib/
If you only call basic_html, markdown_html or strip_tags, the CSS scrubber is not in your path, according to the CNA entry. If you call html5 or a custom scrubber that extends it, you are in scope.
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.
- If you cannot upgrade, switch to basic_html, markdown_html or strip_tags where your product allows, as the entry suggests.
- Or define a custom scrubber that allows neither style elements nor style attributes.
- Cap the size of user supplied HTML before it reaches the sanitizer. The entry notes the cap has to be small to help.
- Add request timeouts and rate limits on endpoints that sanitize user HTML.
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 class is CWE-1333, inefficient regular expression complexity. The pattern matched a property name with an unbounded repeat followed by a required colon. When a long run of word characters has no colon, the engine backs off one character at a time and retries from every starting point, so the work grows with the square of the input length.
The CNA entry gives rough numbers: an 80 KB style body costs about 2.4 seconds of scheduler time, so a few concurrent requests can make an Erlang VM unresponsive. Sanitizers sit on untrusted input by design, which makes performance limits part of security. The record does not mark this CVE as known exploited.
Quick check
Do basic_html and strip_tags have this problem?
The CNA entry says those scrubbers do not reach the CSS scrubber, so they are not affected by this one.
Is data at risk?
No. The entry says the impact is CPU exhaustion only.
Sources
- https://cna.erlef.org/cves/CVE-2026-68749.html
- Record: NVD entry for CVE-2026-68749 (score 7.5, HIGH)
Last reviewed: 18 October 2026.