Safeguard
Vulnerability Analysis•

CVE-2026-68749: High CSS Regex DoS in Elixir html_sanitize_ex

html_sanitize_ex 0.3.1 to before 1.4.5, and 1.5.0-rc.0 to before 1.5.3, has a quadratic regex in its CSS scrubber. Upgrade or use a scrubber without CSS.

Safeguard Security Team
3 min read

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

  1. Upgrade html_sanitize_ex to 1.4.5 on the 1.4 line or 1.5.3 on the 1.5 line, or newer.
  2. If you cannot upgrade, switch to basic_html, markdown_html or strip_tags where your product allows, as the entry suggests.
  3. Or define a custom scrubber that allows neither style elements nor style attributes.
  4. Cap the size of user supplied HTML before it reaches the sanitizer. The entry notes the cap has to be small to help.
  5. 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

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.