https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 16:07:19 +0000 https://db.gcve.eu/vuln/brew-athenacli-cve-2026-59893 <p><strong>Affected:</strong> Homebrew: athenacli</p> <p>### Summary</p> <p>sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at `sqlparse/keywords.py:33` uses a backreference (`\1`) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.</p> <p>**Scope note:** the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see &#34;Additional affected pattern: multiline comments&#34; below.</p> <p>### Details</p> <p>The vulnerable regex is defined in `sqlparse/keywords.py` as part of `SQL_REGEX`:</p> <p>```python # sqlparse/keywords.py:33 (r&#39;((?&lt;![\w\&#34;\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1&#39;, tokens.Literal), ```</p> <p>This pattern first captures a dollar-quote delimiter (e.g., `$tag$`) into group 1, then attempts to match any characters (`[\s\S]*?`) up to the same delimiter again via backreference `\1`. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the r…</p> <p><strong>Affected:</strong> Homebrew: athenacli</p> <p>### Summary</p> <p>sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at `sqlparse/keywords.py:33` uses a backreference (`\1`) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.</p> <p>**Scope note:** the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see &#34;Additional affected pattern: multiline comments&#34; below.</p> <p>### Details</p> <p>The vulnerable regex is defined in `sqlparse/keywords.py` as part of `SQL_REGEX`:</p> <p>```python # sqlparse/keywords.py:33 (r&#39;((?&lt;![\w\&#34;\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1&#39;, tokens.Literal), ```</p> <p>This pattern first captures a dollar-quote delimiter (e.g., `$tag$`) into group 1, then attempts to match any characters (`[\s\S]*?`) up to the same delimiter again via backreference `\1`. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the r…</p> https://db.gcve.eu/vuln/brew-athenacli-cve-2026-59893 https://db.gcve.eu/vuln/certfr-2026-avi-1165 certfr-2026-avi-1165 https://db.gcve.eu/vuln/certfr-2026-avi-1165 https://db.gcve.eu/vuln/cleanstart-2026-ec11110 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: apache-superset</p> <p>Multiple security vulnerabilities affect the apache-superset package. undici&#39;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&#39;s status and headers. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: apache-superset</p> <p>Multiple security vulnerabilities affect the apache-superset package. undici&#39;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&#39;s status and headers. See references for individual vulnerability details.</p> https://db.gcve.eu/vuln/cleanstart-2026-ec11110 https://db.gcve.eu/vuln/fkie_cve-2026-59893 <p>sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, SQL_REGEX in sqlparse/keywords.py and the per-position loop in sqlparse/lexer.py repeatedly scan unmatched dollar-quoted literal and multiline-comment delimiters, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split(). 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, SQL_REGEX in sqlparse/keywords.py and the per-position loop in sqlparse/lexer.py repeatedly scan unmatched dollar-quoted literal and multiline-comment delimiters, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split(). This issue is fixed in version 0.6.0.</p> https://db.gcve.eu/vuln/fkie_cve-2026-59893 https://db.gcve.eu/vuln/ghsa-prg7-hcfm-mfcr <p><strong>Affected:</strong> PyPI: sqlparse</p> <p>### Summary</p> <p>sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at `sqlparse/keywords.py:33` uses a backreference (`\1`) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.</p> <p>**Scope note:** the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see &#34;Additional affected pattern: multiline comments&#34; below.</p> <p>### Details</p> <p>The vulnerable regex is defined in `sqlparse/keywords.py` as part of `SQL_REGEX`:</p> <p>```python # sqlparse/keywords.py:33 (r&#39;((?&lt;![\w\&#34;\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1&#39;, tokens.Literal), ```</p> <p>This pattern first captures a dollar-quote delimiter (e.g., `$tag$`) into group 1, then attempts to match any characters (`[\s\S]*?`) up to the same delimiter again via backreference `\1`. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the r…</p> <p><strong>Affected:</strong> PyPI: sqlparse</p> <p>### Summary</p> <p>sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at `sqlparse/keywords.py:33` uses a backreference (`\1`) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.</p> <p>**Scope note:** the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see &#34;Additional affected pattern: multiline comments&#34; below.</p> <p>### Details</p> <p>The vulnerable regex is defined in `sqlparse/keywords.py` as part of `SQL_REGEX`:</p> <p>```python # sqlparse/keywords.py:33 (r&#39;((?&lt;![\w\&#34;\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1&#39;, tokens.Literal), ```</p> <p>This pattern first captures a dollar-quote delimiter (e.g., `$tag$`) into group 1, then attempts to match any characters (`[\s\S]*?`) up to the same delimiter again via backreference `\1`. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the r…</p> https://db.gcve.eu/vuln/ghsa-prg7-hcfm-mfcr https://db.gcve.eu/vuln/oesa-2026-3547 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: python-sqlparse, openEuler:24.03-LTS-SP1: python-sqlparse, openEuler:24.03-LTS-SP3: python-sqlparse, openEuler:24.03-LTS-SP4: python-sqlparse, openEuler:20.03-LTS-SP4: python-sqlparse</p> <p>A non-validating SQL parser. Security Fix(es):</p> <p>### Summary</p> <p>sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at `sqlparse/keywords.py:33` uses a backreference (`\1`) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.</p> <p>**Scope note:** the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see &amp;quot;Additional affected pattern: multiline comments&amp;quot; below.</p> <p>### Details</p> <p>The vulnerable regex is defined in `sqlparse/keywords.py` as part of `SQL_REGEX`:</p> <p>```python # sqlparse/keywords.py:33 (r&amp;apos;((?&amp;lt;![\w\&amp;quot;\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1&amp;apos;, tokens.Literal), ```</p> <p>This pattern first captures a dollar-quote delimiter (e.g., `$tag$`) into group 1, then attempts to match any characters (`[\s\S]*?`) up to the same delimiter again via backreference `\1`. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a se…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: python-sqlparse, openEuler:24.03-LTS-SP1: python-sqlparse, openEuler:24.03-LTS-SP3: python-sqlparse, openEuler:24.03-LTS-SP4: python-sqlparse, openEuler:20.03-LTS-SP4: python-sqlparse</p> <p>A non-validating SQL parser. Security Fix(es):</p> <p>### Summary</p> <p>sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at `sqlparse/keywords.py:33` uses a backreference (`\1`) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.</p> <p>**Scope note:** the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see &amp;quot;Additional affected pattern: multiline comments&amp;quot; below.</p> <p>### Details</p> <p>The vulnerable regex is defined in `sqlparse/keywords.py` as part of `SQL_REGEX`:</p> <p>```python # sqlparse/keywords.py:33 (r&amp;apos;((?&amp;lt;![\w\&amp;quot;\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1&amp;apos;, tokens.Literal), ```</p> <p>This pattern first captures a dollar-quote delimiter (e.g., `$tag$`) into group 1, then attempts to match any characters (`[\s\S]*?`) up to the same delimiter again via backreference `\1`. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a se…</p> https://db.gcve.eu/vuln/oesa-2026-3547 https://db.gcve.eu/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://db.gcve.eu/vuln/opensuse-su-2026:11557-1 https://db.gcve.eu/vuln/pysec-2026-3698 <p><strong>Affected:</strong> PyPI: sqlparse</p> <p>### Summary</p> <p>sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at `sqlparse/keywords.py:33` uses a backreference (`\1`) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.</p> <p>**Scope note:** the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see &#34;Additional affected pattern: multiline comments&#34; below.</p> <p>### Details</p> <p>The vulnerable regex is defined in `sqlparse/keywords.py` as part of `SQL_REGEX`:</p> <p>```python # sqlparse/keywords.py:33 (r&#39;((?&lt;![\w\&#34;\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1&#39;, tokens.Literal), ```</p> <p>This pattern first captures a dollar-quote delimiter (e.g., `$tag$`) into group 1, then attempts to match any characters (`[\s\S]*?`) up to the same delimiter again via backreference `\1`. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the r…</p> <p><strong>Affected:</strong> PyPI: sqlparse</p> <p>### Summary</p> <p>sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at `sqlparse/keywords.py:33` uses a backreference (`\1`) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.</p> <p>**Scope note:** the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see &#34;Additional affected pattern: multiline comments&#34; below.</p> <p>### Details</p> <p>The vulnerable regex is defined in `sqlparse/keywords.py` as part of `SQL_REGEX`:</p> <p>```python # sqlparse/keywords.py:33 (r&#39;((?&lt;![\w\&#34;\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1&#39;, tokens.Literal), ```</p> <p>This pattern first captures a dollar-quote delimiter (e.g., `$tag$`) into group 1, then attempts to match any characters (`[\s\S]*?`) up to the same delimiter again via backreference `\1`. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the r…</p> https://db.gcve.eu/vuln/pysec-2026-3698 https://db.gcve.eu/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://db.gcve.eu/vuln/rhsa-2026:61783 https://db.gcve.eu/vuln/suse-su-2026:23561-1 <p>Security update for python-sqlparse</p> <p>Security update for python-sqlparse</p> https://db.gcve.eu/vuln/suse-su-2026:23561-1 https://db.gcve.eu/vuln/ubuntu-cve-2026-59893 <p><strong>Affected:</strong> 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, SQL_REGEX in sqlparse/keywords.py and the per-position loop in sqlparse/lexer.py repeatedly scan unmatched dollar-quoted literal and multiline-comment delimiters, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split(). This issue is fixed in version 0.6.0.</p> <p><strong>Affected:</strong> 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, SQL_REGEX in sqlparse/keywords.py and the per-position loop in sqlparse/lexer.py repeatedly scan unmatched dollar-quoted literal and multiline-comment delimiters, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split(). This issue is fixed in version 0.6.0.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-59893