<?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://cve.radiocsirt.org</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 22:12:26 +0000</lastBuildDate>
    <item>
      <title>BREW-athenacli-CVE-2026-71491 — sqlparse: Quadratic O(n²) DoS in group_comments</title>
      <link>https://cve.radiocsirt.org/vuln/brew-athenacli-cve-2026-71491</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: athenacli&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; Homebrew: athenacli&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://cve.radiocsirt.org/vuln/brew-athenacli-cve-2026-71491</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1165 — De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquan…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1165</link>
      <description>certfr-2026-avi-1165</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1165</guid>
    </item>
    <item>
      <title>Withdrawn: CLEANSTART-2026-EC11110 — undici's retry interceptor can append the body of a ranged retry response to bytes already delivered from an earlier pa…</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-ec11110</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: apache-superset&lt;/p&gt;
&lt;p&gt;Multiple security vulnerabilities affect the apache-superset package. undici&amp;#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&amp;#39;s status and headers. See references for individual vulnerability details.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: apache-superset&lt;/p&gt;
&lt;p&gt;Multiple security vulnerabilities affect the apache-superset package. undici&amp;#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&amp;#39;s status and headers. See references for individual vulnerability details.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-ec11110</guid>
    </item>
    <item>
      <title>EUVD-2026-354742</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-354742</link>
      <description>EUVD-2026-354742</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-354742</guid>
    </item>
    <item>
      <title>fkie_cve-2026-71491</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-71491</link>
      <description>&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;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://cve.radiocsirt.org/vuln/fkie_cve-2026-71491</guid>
    </item>
    <item>
      <title>GHSA-f2ff-p2ww-7p4p — sqlparse: Quadratic O(n²) DoS in group_comments</title>
      <link>https://cve.radiocsirt.org/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://cve.radiocsirt.org/vuln/ghsa-f2ff-p2ww-7p4p</guid>
    </item>
    <item>
      <title>OESA-2026-4218 — python-sqlparse security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-4218</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP3: python-sqlparse&lt;/p&gt;
&lt;p&gt;A non-validating SQL parser.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;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)&lt;/p&gt;
&lt;p&gt;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;amp;apos;python&amp;amp;apos; and output_format=&amp;amp;apos;php&amp;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)&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.(CVE-2026-71491)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP3: python-sqlparse&lt;/p&gt;
&lt;p&gt;A non-validating SQL parser.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;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)&lt;/p&gt;
&lt;p&gt;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;amp;apos;python&amp;amp;apos; and output_format=&amp;amp;apos;php&amp;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)&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.(CVE-2026-71491)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-4218</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11557-1 — python313-sqlparse-0.6.0-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11557-1</link>
      <description>&lt;p&gt;python313-sqlparse-0.6.0-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;python313-sqlparse-0.6.0-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11557-1</guid>
    </item>
    <item>
      <title>PYSEC-2026-3697 — sqlparse: Quadratic O(n²) DoS in group_comments</title>
      <link>https://cve.radiocsirt.org/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://cve.radiocsirt.org/vuln/pysec-2026-3697</guid>
    </item>
    <item>
      <title>RHSA-2026:61783 — Red Hat Security Advisory: A Subscription Management tool for finding and reporting Red Hat product usage</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:61783</link>
      <description>&lt;p&gt;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 &amp;#39;X&amp;#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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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 &amp;#39;X&amp;#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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:61783</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23561-1 — Security update for python-sqlparse</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23561-1</link>
      <description>&lt;p&gt;Security update for python-sqlparse&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for python-sqlparse&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:23561-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-71491</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-71491</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&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; 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&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://cve.radiocsirt.org/vuln/ubuntu-cve-2026-71491</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3555 — Red Hat Ansible Automation Platform (automation-controller): Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3555</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3555</guid>
    </item>
  </channel>
</rss>
