CVE-2026-126192: Soup Sieve · General sibling combinator inside :has() matches untrusted HTML in quadratic time
Affects bandcamp-dlSource GCVE Database
Not known to be exploited · CVSS 6.3 Medium.
Data as of 13 Nov 2026, 21:02 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 4.0 | 6.3 |
|---|
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 12 Nov 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 13 Nov 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewbandcamp-dlpkg:brew/bandcamp-dlOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
## Summary Matching a selector that puts a general-sibling combinator inside `:has()`, such as `div:has(a ~ b)`, against untrusted HTML runs in O(n²) time in the number of sibling elements. A single small document with a few thousand siblings ties the process up for a minute of CPU, so an application that runs a fixed selector of this shape over HTML it doesn't control can be stalled by one request. `:has` is powerful, but much in the same way poor regular expressions can be crafted to cause catastrophic backtracking with greedy capturing, has can be used to create non-ideal scenarios that can cause large portions of the tree to be evaluated for one or many elements if not used thoughtfully. This behavior is not exclusive to Soup Sieve, but browsers make note of these potential performance issues themselves: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:has#performance_considerations. With all of that said, there is room for improvements that can in some cases greatly improve performance. ## Details `:has(a ~ b)` asks "does this element contain an `a` that has a later sibling `b`?". When no `b` is present, soupsieve can't short-circuit, and it answers the question with a nested scan: `match_future_child` walks every candidate `a` under the scope, and for each one the general-sibling branch of `match_future_relations` walks all of that `a`'s following siblings looking for `b`. With n siblings that is (n-1) + (n-2) + ... + 1 comparisons, i.e. O(n²). The adjacent-sibling form `div:has(a + b)` stays linear, because its branch checks only the one immediately following sibling per candidate. So the cost is specific to the general-sibling `~` (and `~` nested inside `:has`), and it shows up on the common case where the right-hand side simply isn't there. ## Proof of concept Installed from PyPI: `pip install soupsieve==2.9.2 beautifulsoup4`. ```python import time import soupsieve from bs4 import BeautifulSoup selector = "div:has(a ~ b)" for n in (1000, 2000, 4000, 8000): html = "<div>" + ("<a></a>" * n) + "</div>" soup = BeautifulSoup(html, "html.parser") start = time.perf_counter() soupsieve.select(selector, soup) print(n, round((time.perf_counter() - start) * 1000), "ms") ``` Measured: ``` n=1000 837 ms n=2000 3667 ms n=4000 14797 ms n=8000 59746 ms ``` Time quadruples for each doubling of n. The n=8000 input is a ~56 KB HTML fragment. ## Impact Availability. Any caller that evaluates a fixed selector containing a general sibling under `:has()` over attacker-controlled markup can be forced to spend minutes of CPU on a small input. The selector is developer-authored and ordinary; the untrusted part is the HTML, which is soupsieve's normal input. A single-pass evaluation of the sibling run (remember whether an `a` has been seen while scanning the siblings once) would make this case linear. ## Mitigation Quadratic time for `:has` in some circumstances is expected and not a bug. While we've made optimizations and there may be more in the future, the way `:has` is designed to operate will never perform in linear time in all circumstances. Users should thoughtfully apply the use of `:has`. The anchor selector (the `A` in `A:has(B)`) should not be an element that has too many children. Additionally, too general an anchor, such as `*`, can cause `:has()` to be applied to every element. Further, it is recommended that the inner selector (the `B` in `A:has(B)`) should use combinators like `>` or `+` to limit traversal. When the selector inside `:has()` is not tightly constrained, Soup Sieve might need to traverse the entire subtree of the anchor element to check the condition. If the risk for a given project is too great, user input can be scanned for usage of `:has` and be denied. Calls can also be wrapped in a timeout to prevent long-running processes as well.
References
- github.com/facelessuser/soupsieve/security/advisories/GHSA-4j63-6c4x-wfg4 (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-126192 (opens in a new tab)
- github.com/facelessuser/soupsieve/pull/304 (opens in a new tab)
- github.com/facelessuser/soupsieve/commit/ffb88cca745c591224f74a8e86414a85e8f35fc0 (opens in a new tab)
- github.com/facelessuser/soupsieve (opens in a new tab)
- github.com/facelessuser/soupsieve/releases/tag/2.10 (opens in a new tab)