GHSA-4j63-6c4x-wfg4

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.

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.