Affected: Homebrew: athenacli

### Summary A comment-only statement (`-- c\n`*n) may cause a Denial of Service (DoS).

### 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)`.

A statement made of many single-line comments (`'-- c\n'` repeated) lexes in O(n) but `group_comments` is O(n²):

```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) ```

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.

Two following factors increase the severity:

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…

Withdrawn by the publisher.

Affected: CleanStart: apache-superset

Multiple security vulnerabilities affect the apache-superset package. undici's retry interceptor can append the body of a ranged retry response to bytes already delivered from an earlier partial response while still presenting the original response's status and headers. See references for individual vulnerability details.

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.

Affected: PyPI: sqlparse

### Summary A comment-only statement (`-- c\n`*n) may cause a Denial of Service (DoS).

### 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)`.

A statement made of many single-line comments (`'-- c\n'` repeated) lexes in O(n) but `group_comments` is O(n²):

```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) ```

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.

Two following factors increase the severity:

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…

Affected: openEuler:24.03-LTS-SP3: python-sqlparse

A non-validating SQL parser. Security Fix(es):

sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, TokenList construction and string conversion in sqlparse/sql.py repeatedly flatten nested token subtrees constructed by group_parenthesis and group_case, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split() before depth and token limits terminate processing. This issue is fixed in version 0.6.0.(CVE-2026-54284)

sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, sqlparse/filters/output.py fails to escape existing backslashes before quotes in sqlparse.format output_format='python' and output_format='php' and the corresponding sqlformat -l modes, allowing crafted SQL to terminate the generated string and inject Python or PHP code when a downstream consumer executes or imports the generated source. This issue is fixed in version 0.6.0.(CVE-2026-59894)

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.(CVE-2026-71491)

python313-sqlparse-0.6.0-1.1 on GA media

Affected: PyPI: sqlparse

### Summary A comment-only statement (`-- c\n`*n) may cause a Denial of Service (DoS).

### 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)`.

A statement made of many single-line comments (`'-- c\n'` repeated) lexes in O(n) but `group_comments` is O(n²):

```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) ```

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.

Two following factors increase the severity:

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…

webpack-dev-middleware: lack of URL validation may lead to file leak curl: curl: Authentication bypass due to incorrect connection reuse with Negotiate authentication curl: curl: Information disclosure via OAuth2 bearer token leakage during HTTP(S) redirect tar: tar: Hidden file injection via crafted archives fast-uri: fast-uri: URI authority bypass due to improper delimiter handling libxml2: mingw-libxml2: libxml2: Denial of Service via crafted XML input due to use-after-free curl: curl: Insecure connection establishment due to TLS configuration mismatch curl: curl: Man-in-the-middle attack via SSH host key bypass sqlite: SQLite: Arbitrary code execution via crafted FTS5 full-text search data sqlite: SQLite: Arbitrary code execution and crash via heap-based buffer overflow in FTS5 libxml2: libxml2: Arbitrary code execution in xmlcatalog utility via buffer overflow libarchive: Double-Free Vulnerability in RAR5 Decompression Logic via dangling filtered_buf pointer in init_unpack() GDBusServer: glib2: GDBusServer pre-authentication DoS via unbounded SASL line buffering tar: tar: TOCTOU in incremental dumpdir 'X' rename handling allows restore path escape tar: tar: --one-top-level hardlink targets not confined to top-level directory enabling arbitrary file overwrite gzip: gzip: Arbitrary file overwrite via insecure temporary file handling in gzexe utility gzip: gzip: Information disclosure via global buffer overflow in LZH decompression python-idna: idna: Denial of Service via…

Security update for python-sqlparse

Affected: Ubuntu:Pro:16.04:LTS: sqlparse, Ubuntu:Pro:18.04:LTS: sqlparse, Ubuntu:Pro:20.04:LTS: sqlparse, Ubuntu:22.04:LTS: sqlparse, Ubuntu:24.04:LTS: sqlparse, Ubuntu:26.04:LTS: sqlparse

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.

Ein Angreifer kann mehrere Schwachstellen in Red Hat Ansible Automation Platform ausnutzen, um seine Privilegien zu erhöhen, beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen und einen Denial-of-Service-Zustand herbeizuführen.