GHSA-r8cj-3554-33mr — justhtml
GHSA-r8cj-3554-33mr is a Uncontrolled Resource Consumption vulnerability in justhtml. A fix is available for justhtml — see the affected versions and patch details below.
justhtml introduces denial-of-service hardening
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-r8cj-3554-33mr.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
justhtmlReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
justhtml 1.18.0 fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.
These issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.
Affected versions
justhtml< 1.18.0
Fixed version
justhtml1.18.0released on May 4, 2026
Impact
CSS selector handling
Applications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.
The affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as :not(...), repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and :contains(...) over large descendant text.
Programmatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for :contains(...).
Linkification
Attacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.
Default configuration
Ordinary sanitization of parsed HTML with the default JustHTML(..., sanitize=True) configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.
The main risk areas are:
- applications that accept selector strings from untrusted users and pass them to
query(...),matches(...), or selector-based transforms - custom transform or sanitization pipelines that run selector matching over very large untrusted documents
- applications that construct or mutate DOM trees programmatically from untrusted structure
- applications that enable
Linkify(...)over attacker-controlled text
Fixes in 1.18.0
1.18.0 adds generalized selector resource controls and removes several repeated-work hot paths:
- shared selector limits for parse and match operations
- structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth
- match-operation and string-byte budgets
- per-query matcher state for caches and cycle guards
- precomputed or cached ancestor, sibling, positional, attribute-token, text-content,
:not(...),:empty, and:nth-child(...)work - consistent enforcement across public parsing,
query(...), tag-only query fast paths, transform selector compilation, and sanitization transform matching - linkification hardening for punctuation-heavy inputs and trailing bracket trimming
CWE mapping
- CWE-400: Uncontrolled Resource Consumption
- CWE-407: Inefficient Algorithmic Complexity
- CWE-835: Loop with Unreachable Exit Condition
Recommended action
Upgrade to justhtml 1.18.0.
If users cannot upgrade immediately:
- do not pass untrusted selector strings to
query(...),matches(...), or selector-based transforms - restrict the size of untrusted documents before selector matching or linkification
- avoid constructing programmatic DOM graphs from untrusted structure
- avoid enabling
Linkify(...)on very large attacker-controlled text
Credit
Discovered during an internal security review of justhtml.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | justhtml | all versions | 1.18.0pip install --upgrade 'justhtml==1.18.0' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for justhtml, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update justhtml to 1.18.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r8cj-3554-33mr is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-r8cj-3554-33mr can be triaged on real exposure rather than presence alone.
Tailored to GHSA-r8cj-3554-33mr. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-r8cj-3554-33mr in your dependencies?
O3 Security finds GHSA-r8cj-3554-33mr across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.