<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 09:57:29 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-71491 — sqlparse: Quadratic O(n²) DoS in group_comments</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-71491</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; andialbrecht sqlparse&lt;/p&gt;
&lt;p&gt;sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, group_comments in sqlparse/engine/grouping.py repeatedly rescans comment-only statements before the MAX_GROUPING_TOKENS guard, causing quadratic CPU consumption through sqlparse.parse() and sqlparse.format(sql, strip_comments=True). This issue is fixed in version 0.6.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; andialbrecht sqlparse&lt;/p&gt;
&lt;p&gt;sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, group_comments in sqlparse/engine/grouping.py repeatedly rescans comment-only statements before the MAX_GROUPING_TOKENS guard, causing quadratic CPU consumption through sqlparse.parse() and sqlparse.format(sql, strip_comments=True). This issue is fixed in version 0.6.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-71491</guid>
    </item>
    <item>
      <title>GHSA-f2ff-p2ww-7p4p — sqlparse: Quadratic O(n²) DoS in group_comments</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-f2ff-p2ww-7p4p</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: sqlparse&lt;/p&gt;
&lt;p&gt;### Summary
A comment-only statement (`-- c\n`*n) may cause a Denial of Service (DoS).&lt;/p&gt;
&lt;p&gt;### Details
Location: [sqlparse/engine/grouping.py:331-341](https://github.com/andialbrecht/sqlparse/blob/f80af6a4007f11ada847218df8c29dc859238290/sqlparse/engine/grouping.py#L332) (`group_comments`), invoked first in `group()` at `grouping.py:439`. Reachable via `sqlparse.parse()` and `sqlparse.format(sql, strip_comments=True)`.&lt;/p&gt;
&lt;p&gt;A statement made of many single-line comments (`&amp;#39;-- c\n&amp;#39;` repeated) lexes in O(n) but `group_comments` is O(n²):&lt;/p&gt;
&lt;p&gt;```python
def group_comments(tlist):
    tidx, token = tlist.token_next_by(t=T.Comment)
    while token:
        eidx, end = tlist.token_not_matching(
            lambda tk: imt(tk, t=T.Comment) or tk.is_newline, idx=tidx)
        ...
        tidx, token = tlist.token_next_by(t=T.Comment, idx=tidx)
```&lt;/p&gt;
&lt;p&gt;The `while` loop runs n times and each `token_next_by` / `token_not_matching` rescans the O(n) remaining tokens. When all tokens are comments/newlines nothing ever groups, yet the full scan is repeated per token.&lt;/p&gt;
&lt;p&gt;Two following factors increase the severity:&lt;/p&gt;
&lt;p&gt;1. `group_comments` runs first in `group()` (`grouping.py:439`), before the `_group_matching` token-count guard (`grouping.py:34-39`). So the entire quadratic cost is paid even on oversized input. `MAX_GROUPING_TOKENS` does not provide protection on this vector.
2. It sits on the primary sanitizer path: `format(sql, strip_comments=True)`, used by query loggers, SQL firewalls, ORMs, and migration…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: sqlparse&lt;/p&gt;
&lt;p&gt;### Summary
A comment-only statement (`-- c\n`*n) may cause a Denial of Service (DoS).&lt;/p&gt;
&lt;p&gt;### Details
Location: [sqlparse/engine/grouping.py:331-341](https://github.com/andialbrecht/sqlparse/blob/f80af6a4007f11ada847218df8c29dc859238290/sqlparse/engine/grouping.py#L332) (`group_comments`), invoked first in `group()` at `grouping.py:439`. Reachable via `sqlparse.parse()` and `sqlparse.format(sql, strip_comments=True)`.&lt;/p&gt;
&lt;p&gt;A statement made of many single-line comments (`&amp;#39;-- c\n&amp;#39;` repeated) lexes in O(n) but `group_comments` is O(n²):&lt;/p&gt;
&lt;p&gt;```python
def group_comments(tlist):
    tidx, token = tlist.token_next_by(t=T.Comment)
    while token:
        eidx, end = tlist.token_not_matching(
            lambda tk: imt(tk, t=T.Comment) or tk.is_newline, idx=tidx)
        ...
        tidx, token = tlist.token_next_by(t=T.Comment, idx=tidx)
```&lt;/p&gt;
&lt;p&gt;The `while` loop runs n times and each `token_next_by` / `token_not_matching` rescans the O(n) remaining tokens. When all tokens are comments/newlines nothing ever groups, yet the full scan is repeated per token.&lt;/p&gt;
&lt;p&gt;Two following factors increase the severity:&lt;/p&gt;
&lt;p&gt;1. `group_comments` runs first in `group()` (`grouping.py:439`), before the `_group_matching` token-count guard (`grouping.py:34-39`). So the entire quadratic cost is paid even on oversized input. `MAX_GROUPING_TOKENS` does not provide protection on this vector.
2. It sits on the primary sanitizer path: `format(sql, strip_comments=True)`, used by query loggers, SQL firewalls, ORMs, and migration…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-f2ff-p2ww-7p4p</guid>
    </item>
    <item>
      <title>PYSEC-2026-3697 — sqlparse: Quadratic O(n²) DoS in group_comments</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-3697</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: sqlparse&lt;/p&gt;
&lt;p&gt;### Summary
A comment-only statement (`-- c\n`*n) may cause a Denial of Service (DoS).&lt;/p&gt;
&lt;p&gt;### Details
Location: [sqlparse/engine/grouping.py:331-341](https://github.com/andialbrecht/sqlparse/blob/f80af6a4007f11ada847218df8c29dc859238290/sqlparse/engine/grouping.py#L332) (`group_comments`), invoked first in `group()` at `grouping.py:439`. Reachable via `sqlparse.parse()` and `sqlparse.format(sql, strip_comments=True)`.&lt;/p&gt;
&lt;p&gt;A statement made of many single-line comments (`&amp;#39;-- c\n&amp;#39;` repeated) lexes in O(n) but `group_comments` is O(n²):&lt;/p&gt;
&lt;p&gt;```python
def group_comments(tlist):
    tidx, token = tlist.token_next_by(t=T.Comment)
    while token:
        eidx, end = tlist.token_not_matching(
            lambda tk: imt(tk, t=T.Comment) or tk.is_newline, idx=tidx)
        ...
        tidx, token = tlist.token_next_by(t=T.Comment, idx=tidx)
```&lt;/p&gt;
&lt;p&gt;The `while` loop runs n times and each `token_next_by` / `token_not_matching` rescans the O(n) remaining tokens. When all tokens are comments/newlines nothing ever groups, yet the full scan is repeated per token.&lt;/p&gt;
&lt;p&gt;Two following factors increase the severity:&lt;/p&gt;
&lt;p&gt;1. `group_comments` runs first in `group()` (`grouping.py:439`), before the `_group_matching` token-count guard (`grouping.py:34-39`). So the entire quadratic cost is paid even on oversized input. `MAX_GROUPING_TOKENS` does not provide protection on this vector.
2. It sits on the primary sanitizer path: `format(sql, strip_comments=True)`, used by query loggers, SQL firewalls, ORMs, and migration…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: sqlparse&lt;/p&gt;
&lt;p&gt;### Summary
A comment-only statement (`-- c\n`*n) may cause a Denial of Service (DoS).&lt;/p&gt;
&lt;p&gt;### Details
Location: [sqlparse/engine/grouping.py:331-341](https://github.com/andialbrecht/sqlparse/blob/f80af6a4007f11ada847218df8c29dc859238290/sqlparse/engine/grouping.py#L332) (`group_comments`), invoked first in `group()` at `grouping.py:439`. Reachable via `sqlparse.parse()` and `sqlparse.format(sql, strip_comments=True)`.&lt;/p&gt;
&lt;p&gt;A statement made of many single-line comments (`&amp;#39;-- c\n&amp;#39;` repeated) lexes in O(n) but `group_comments` is O(n²):&lt;/p&gt;
&lt;p&gt;```python
def group_comments(tlist):
    tidx, token = tlist.token_next_by(t=T.Comment)
    while token:
        eidx, end = tlist.token_not_matching(
            lambda tk: imt(tk, t=T.Comment) or tk.is_newline, idx=tidx)
        ...
        tidx, token = tlist.token_next_by(t=T.Comment, idx=tidx)
```&lt;/p&gt;
&lt;p&gt;The `while` loop runs n times and each `token_next_by` / `token_not_matching` rescans the O(n) remaining tokens. When all tokens are comments/newlines nothing ever groups, yet the full scan is repeated per token.&lt;/p&gt;
&lt;p&gt;Two following factors increase the severity:&lt;/p&gt;
&lt;p&gt;1. `group_comments` runs first in `group()` (`grouping.py:439`), before the `_group_matching` token-count guard (`grouping.py:34-39`). So the entire quadratic cost is paid even on oversized input. `MAX_GROUPING_TOKENS` does not provide protection on this vector.
2. It sits on the primary sanitizer path: `format(sql, strip_comments=True)`, used by query loggers, SQL firewalls, ORMs, and migration…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-3697</guid>
    </item>
  </channel>
</rss>
