https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 21:36:19 +0000 https://db.gcve.eu/vuln/cve-2026-85999 <p><strong>Affected:</strong> facelessuser soupsieve</p> <p>Soup Sieve is a CSS selector library designed to be used with Beautiful Soup 4. Prior to 2.9, selector_iter in src/soupsieve/css_parser.py trims the raw selector with RE_WS_END, an end-anchored WSC whitespace-and-comment expression used with search(), so the regular expression engine retries a greedy scan at every starting offset. An attacker-controlled valid selector containing a long internal whitespace run, or a selector containing a long CSS comment run followed by another token, causes quadratic CPU work before tokenization. User-controlled selectors can reach the path through soupsieve.compile() and BeautifulSoup.select(), while applications using only hard-coded selectors are unaffected. This root cause is separate from the IDENTIFIER and VALUE backtracking vulnerability because the cost occurs in RE_WS_END.search during trimming rather than token matching. The resulting CPU consumption can hold the Python GIL, exhaust workers, and stall a service without causing memory corruption or code execution. The issue is fixed in version 2.9.</p> <p><strong>Affected:</strong> facelessuser soupsieve</p> <p>Soup Sieve is a CSS selector library designed to be used with Beautiful Soup 4. Prior to 2.9, selector_iter in src/soupsieve/css_parser.py trims the raw selector with RE_WS_END, an end-anchored WSC whitespace-and-comment expression used with search(), so the regular expression engine retries a greedy scan at every starting offset. An attacker-controlled valid selector containing a long internal whitespace run, or a selector containing a long CSS comment run followed by another token, causes quadratic CPU work before tokenization. User-controlled selectors can reach the path through soupsieve.compile() and BeautifulSoup.select(), while applications using only hard-coded selectors are unaffected. This root cause is separate from the IDENTIFIER and VALUE backtracking vulnerability because the cost occurs in RE_WS_END.search during trimming rather than token matching. The resulting CPU consumption can hold the Python GIL, exhaust workers, and stall a service without causing memory corruption or code execution. The issue is fixed in version 2.9.</p> https://db.gcve.eu/vuln/cve-2026-85999 https://db.gcve.eu/vuln/ghsa-j934-xhv5-fg8f <p><strong>Affected:</strong> PyPI: soupsieve</p> <p>## Summary</p> <p>Before tokenizing, `selector_iter` trims leading/trailing whitespace and comments by running two regexes over the whole raw selector with `.search()`. The trailing one, `RE_WS_END = re.compile(r&#39;{WSC}*$&#39;)`, is anchored only at the end (`$`), not the start. Because `.search()` retries the pattern at every offset, a long run of whitespace or CSS comments that is not sitting exactly at the end of the string makes each retry greedily consume the run and then fail `$`, producing O(n²) time. This triggers on perfectly valid selectors — e.g. a descendant combinator with a long whitespace gap, `a` + `&#34; &#34;*n` + `b` — so no malformed input is required. A single valid ~20 KB selector stalls the interpreter for ~10 s of CPU.</p> <p>## Trust model (Q0)</p> <p>The selector string is the input, reaching this code via `soupsieve.compile()`, the `soupsieve.select/iselect/match/filter` helpers, and BeautifulSoup&#39;s `soup.select(selector)` / `soup.select_one(selector)`. Exploitable wherever an application passes a user-controlled CSS selector to BeautifulSoup/soupsieve. Applications using only hard-coded selectors are unaffected.</p> <p>## Root cause (exact anchors) — `src/soupsieve/css_parser.py`</p> <p>```python # line 185-186 RE_WS_BEGIN = re.compile(fr&#39;^{WSC}*&#39;) # anchored at start -&gt; .search() only tries pos 0 -&gt; linear (safe) RE_WS_END = re.compile(fr&#39;{WSC}*$&#39;) # NOT anchored at start -&gt; .search() tries every offset</p> <p># selector_iter, lines ~1322-1326 m = RE_WS_BEGIN.search(pattern) index = m.end…</p> <p><strong>Affected:</strong> PyPI: soupsieve</p> <p>## Summary</p> <p>Before tokenizing, `selector_iter` trims leading/trailing whitespace and comments by running two regexes over the whole raw selector with `.search()`. The trailing one, `RE_WS_END = re.compile(r&#39;{WSC}*$&#39;)`, is anchored only at the end (`$`), not the start. Because `.search()` retries the pattern at every offset, a long run of whitespace or CSS comments that is not sitting exactly at the end of the string makes each retry greedily consume the run and then fail `$`, producing O(n²) time. This triggers on perfectly valid selectors — e.g. a descendant combinator with a long whitespace gap, `a` + `&#34; &#34;*n` + `b` — so no malformed input is required. A single valid ~20 KB selector stalls the interpreter for ~10 s of CPU.</p> <p>## Trust model (Q0)</p> <p>The selector string is the input, reaching this code via `soupsieve.compile()`, the `soupsieve.select/iselect/match/filter` helpers, and BeautifulSoup&#39;s `soup.select(selector)` / `soup.select_one(selector)`. Exploitable wherever an application passes a user-controlled CSS selector to BeautifulSoup/soupsieve. Applications using only hard-coded selectors are unaffected.</p> <p>## Root cause (exact anchors) — `src/soupsieve/css_parser.py`</p> <p>```python # line 185-186 RE_WS_BEGIN = re.compile(fr&#39;^{WSC}*&#39;) # anchored at start -&gt; .search() only tries pos 0 -&gt; linear (safe) RE_WS_END = re.compile(fr&#39;{WSC}*$&#39;) # NOT anchored at start -&gt; .search() tries every offset</p> <p># selector_iter, lines ~1322-1326 m = RE_WS_BEGIN.search(pattern) index = m.end…</p> https://db.gcve.eu/vuln/ghsa-j934-xhv5-fg8f