https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 11:41:24 +0000 https://cve.radiocsirt.org/vuln/brew-athenacli-cve-2026-54284 <p><strong>Affected:</strong> Homebrew: athenacli</p> <p>### Summary</p> <p>`sqlparse` ships hard limits (`MAX_GROUPING_DEPTH=100`, `MAX_GROUPING_TOKENS=10000`) intended to bound parsing work on attacker-supplied SQL, but the path that *reaches* those limits is itself `O(n*depth)` per token-group construction. A ~1-2 KB SQL payload (e.g. `SELECT (((((1))))) ...` with 500-2000 nesting levels, or a 200-400-level nested `CASE WHEN` chain) drives the parser to spend multiple seconds of CPU before the depth cap raises `SQLParseError`. Concretely: a 2 KB malicious payload consumes ~10 seconds of CPU per request on a single worker (~5000x CPU-to-input amplification), while a benign 1 KB SQL completes in ~3 ms.</p> <p>The root cause is `TokenList.__init__` calling `super().__init__(None, str(self))`. `TokenList.__str__` flattens the entire subtree on every call, and grouping constructs a new `TokenList` for every parenthesis / CASE / list group, so a tree of depth `d` with `n` total tokens performs `O(n*d)` flatten work just to materialize the cached `value` field, which is then never read for grouped nodes (they override `__str__`).</p> <p>This is a distinct quadratic from the input-size caps added in GHSA-2m57-hf25-phgg / GHSA-27jp-wm6q-gp25: those caps prevent unbounded work, but the time required to *trigger* the caps is itself superlinear in payload size.</p> <p>### Affected components</p> <p>`sqlparse` 0.5.5 (latest) and every prior version that ships `TokenList.__init__`. The offending line has existed since the introduction of the cached-value invariant; the r…</p> <p><strong>Affected:</strong> Homebrew: athenacli</p> <p>### Summary</p> <p>`sqlparse` ships hard limits (`MAX_GROUPING_DEPTH=100`, `MAX_GROUPING_TOKENS=10000`) intended to bound parsing work on attacker-supplied SQL, but the path that *reaches* those limits is itself `O(n*depth)` per token-group construction. A ~1-2 KB SQL payload (e.g. `SELECT (((((1))))) ...` with 500-2000 nesting levels, or a 200-400-level nested `CASE WHEN` chain) drives the parser to spend multiple seconds of CPU before the depth cap raises `SQLParseError`. Concretely: a 2 KB malicious payload consumes ~10 seconds of CPU per request on a single worker (~5000x CPU-to-input amplification), while a benign 1 KB SQL completes in ~3 ms.</p> <p>The root cause is `TokenList.__init__` calling `super().__init__(None, str(self))`. `TokenList.__str__` flattens the entire subtree on every call, and grouping constructs a new `TokenList` for every parenthesis / CASE / list group, so a tree of depth `d` with `n` total tokens performs `O(n*d)` flatten work just to materialize the cached `value` field, which is then never read for grouped nodes (they override `__str__`).</p> <p>This is a distinct quadratic from the input-size caps added in GHSA-2m57-hf25-phgg / GHSA-27jp-wm6q-gp25: those caps prevent unbounded work, but the time required to *trigger* the caps is itself superlinear in payload size.</p> <p>### Affected components</p> <p>`sqlparse` 0.5.5 (latest) and every prior version that ships `TokenList.__init__`. The offending line has existed since the introduction of the cached-value invariant; the r…</p> https://cve.radiocsirt.org/vuln/brew-athenacli-cve-2026-54284 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1165 certfr-2026-avi-1165 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1165 https://cve.radiocsirt.org/vuln/cleanstart-2026-aa29461 <p><strong>Affected:</strong> CleanStart: airflow-3</p> <p>Security vulnerability affects the airflow-3 package. sqlparse is a non-validating SQL parser module for Python.</p> <p><strong>Affected:</strong> CleanStart: airflow-3</p> <p>Security vulnerability affects the airflow-3 package. sqlparse is a non-validating SQL parser module for Python.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-aa29461 https://cve.radiocsirt.org/vuln/euvd-2026-354554 EUVD-2026-354554 https://cve.radiocsirt.org/vuln/euvd-2026-354554 https://cve.radiocsirt.org/vuln/fkie_cve-2026-54284 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-54284 https://cve.radiocsirt.org/vuln/ghsa-pwgv-4x5q-6m9f <p><strong>Affected:</strong> PyPI: sqlparse</p> <p>### Summary</p> <p>`sqlparse` ships hard limits (`MAX_GROUPING_DEPTH=100`, `MAX_GROUPING_TOKENS=10000`) intended to bound parsing work on attacker-supplied SQL, but the path that *reaches* those limits is itself `O(n*depth)` per token-group construction. A ~1-2 KB SQL payload (e.g. `SELECT (((((1))))) ...` with 500-2000 nesting levels, or a 200-400-level nested `CASE WHEN` chain) drives the parser to spend multiple seconds of CPU before the depth cap raises `SQLParseError`. Concretely: a 2 KB malicious payload consumes ~10 seconds of CPU per request on a single worker (~5000x CPU-to-input amplification), while a benign 1 KB SQL completes in ~3 ms.</p> <p>The root cause is `TokenList.__init__` calling `super().__init__(None, str(self))`. `TokenList.__str__` flattens the entire subtree on every call, and grouping constructs a new `TokenList` for every parenthesis / CASE / list group, so a tree of depth `d` with `n` total tokens performs `O(n*d)` flatten work just to materialize the cached `value` field, which is then never read for grouped nodes (they override `__str__`).</p> <p>This is a distinct quadratic from the input-size caps added in GHSA-2m57-hf25-phgg / GHSA-27jp-wm6q-gp25: those caps prevent unbounded work, but the time required to *trigger* the caps is itself superlinear in payload size.</p> <p>### Affected components</p> <p>`sqlparse` 0.5.5 (latest) and every prior version that ships `TokenList.__init__`. The offending line has existed since the introduction of the cached-value invariant; the r…</p> <p><strong>Affected:</strong> PyPI: sqlparse</p> <p>### Summary</p> <p>`sqlparse` ships hard limits (`MAX_GROUPING_DEPTH=100`, `MAX_GROUPING_TOKENS=10000`) intended to bound parsing work on attacker-supplied SQL, but the path that *reaches* those limits is itself `O(n*depth)` per token-group construction. A ~1-2 KB SQL payload (e.g. `SELECT (((((1))))) ...` with 500-2000 nesting levels, or a 200-400-level nested `CASE WHEN` chain) drives the parser to spend multiple seconds of CPU before the depth cap raises `SQLParseError`. Concretely: a 2 KB malicious payload consumes ~10 seconds of CPU per request on a single worker (~5000x CPU-to-input amplification), while a benign 1 KB SQL completes in ~3 ms.</p> <p>The root cause is `TokenList.__init__` calling `super().__init__(None, str(self))`. `TokenList.__str__` flattens the entire subtree on every call, and grouping constructs a new `TokenList` for every parenthesis / CASE / list group, so a tree of depth `d` with `n` total tokens performs `O(n*d)` flatten work just to materialize the cached `value` field, which is then never read for grouped nodes (they override `__str__`).</p> <p>This is a distinct quadratic from the input-size caps added in GHSA-2m57-hf25-phgg / GHSA-27jp-wm6q-gp25: those caps prevent unbounded work, but the time required to *trigger* the caps is itself superlinear in payload size.</p> <p>### Affected components</p> <p>`sqlparse` 0.5.5 (latest) and every prior version that ships `TokenList.__init__`. The offending line has existed since the introduction of the cached-value invariant; the r…</p> https://cve.radiocsirt.org/vuln/ghsa-pwgv-4x5q-6m9f https://cve.radiocsirt.org/vuln/oesa-2026-4218 <p><strong>Affected:</strong> openEuler:24.03-LTS-SP3: python-sqlparse</p> <p>A non-validating SQL parser. Security Fix(es):</p> <p>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)</p> <p>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=&amp;apos;python&amp;apos; and output_format=&amp;apos;php&amp;apos; 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)</p> <p>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)</p> <p><strong>Affected:</strong> openEuler:24.03-LTS-SP3: python-sqlparse</p> <p>A non-validating SQL parser. Security Fix(es):</p> <p>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)</p> <p>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=&amp;apos;python&amp;apos; and output_format=&amp;apos;php&amp;apos; 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)</p> <p>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)</p> https://cve.radiocsirt.org/vuln/oesa-2026-4218 https://cve.radiocsirt.org/vuln/opensuse-su-2026:11557-1 <p>python313-sqlparse-0.6.0-1.1 on GA media</p> <p>python313-sqlparse-0.6.0-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11557-1 https://cve.radiocsirt.org/vuln/pysec-2026-3699 <p><strong>Affected:</strong> PyPI: sqlparse</p> <p>### Summary</p> <p>`sqlparse` ships hard limits (`MAX_GROUPING_DEPTH=100`, `MAX_GROUPING_TOKENS=10000`) intended to bound parsing work on attacker-supplied SQL, but the path that *reaches* those limits is itself `O(n*depth)` per token-group construction. A ~1-2 KB SQL payload (e.g. `SELECT (((((1))))) ...` with 500-2000 nesting levels, or a 200-400-level nested `CASE WHEN` chain) drives the parser to spend multiple seconds of CPU before the depth cap raises `SQLParseError`. Concretely: a 2 KB malicious payload consumes ~10 seconds of CPU per request on a single worker (~5000x CPU-to-input amplification), while a benign 1 KB SQL completes in ~3 ms.</p> <p>The root cause is `TokenList.__init__` calling `super().__init__(None, str(self))`. `TokenList.__str__` flattens the entire subtree on every call, and grouping constructs a new `TokenList` for every parenthesis / CASE / list group, so a tree of depth `d` with `n` total tokens performs `O(n*d)` flatten work just to materialize the cached `value` field, which is then never read for grouped nodes (they override `__str__`).</p> <p>This is a distinct quadratic from the input-size caps added in GHSA-2m57-hf25-phgg / GHSA-27jp-wm6q-gp25: those caps prevent unbounded work, but the time required to *trigger* the caps is itself superlinear in payload size.</p> <p>### Affected components</p> <p>`sqlparse` 0.5.5 (latest) and every prior version that ships `TokenList.__init__`. The offending line has existed since the introduction of the cached-value invariant; the r…</p> <p><strong>Affected:</strong> PyPI: sqlparse</p> <p>### Summary</p> <p>`sqlparse` ships hard limits (`MAX_GROUPING_DEPTH=100`, `MAX_GROUPING_TOKENS=10000`) intended to bound parsing work on attacker-supplied SQL, but the path that *reaches* those limits is itself `O(n*depth)` per token-group construction. A ~1-2 KB SQL payload (e.g. `SELECT (((((1))))) ...` with 500-2000 nesting levels, or a 200-400-level nested `CASE WHEN` chain) drives the parser to spend multiple seconds of CPU before the depth cap raises `SQLParseError`. Concretely: a 2 KB malicious payload consumes ~10 seconds of CPU per request on a single worker (~5000x CPU-to-input amplification), while a benign 1 KB SQL completes in ~3 ms.</p> <p>The root cause is `TokenList.__init__` calling `super().__init__(None, str(self))`. `TokenList.__str__` flattens the entire subtree on every call, and grouping constructs a new `TokenList` for every parenthesis / CASE / list group, so a tree of depth `d` with `n` total tokens performs `O(n*d)` flatten work just to materialize the cached `value` field, which is then never read for grouped nodes (they override `__str__`).</p> <p>This is a distinct quadratic from the input-size caps added in GHSA-2m57-hf25-phgg / GHSA-27jp-wm6q-gp25: those caps prevent unbounded work, but the time required to *trigger* the caps is itself superlinear in payload size.</p> <p>### Affected components</p> <p>`sqlparse` 0.5.5 (latest) and every prior version that ships `TokenList.__init__`. The offending line has existed since the introduction of the cached-value invariant; the r…</p> https://cve.radiocsirt.org/vuln/pysec-2026-3699 https://cve.radiocsirt.org/vuln/rhsa-2026:61783 <p>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 &#39;X&#39; 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…</p> <p>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 &#39;X&#39; 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…</p> https://cve.radiocsirt.org/vuln/rhsa-2026:61783 https://cve.radiocsirt.org/vuln/suse-su-2026:23561-1 <p>Security update for python-sqlparse</p> <p>Security update for python-sqlparse</p> https://cve.radiocsirt.org/vuln/suse-su-2026:23561-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54284 <p><strong>Affected:</strong> 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</p> <p>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.</p> <p><strong>Affected:</strong> 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</p> <p>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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54284 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3555 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3555