https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 09:09:05 +0000 https://cve.radiocsirt.org/vuln/brew-cycode-cve-2026-53539 <p><strong>Affected:</strong> Homebrew: cycode</p> <p>### Summary</p> <p>When parsing `application/x-www-form-urlencoded` bodies, `QuerystringParser` located the field separator with a two step lookup: it first scanned the entire remaining buffer for `&amp;`, and only when no `&amp;` existed anywhere ahead did it fall back to scanning for `;`. For a body that uses `;` as the separator and contains no `&amp;`, every field iteration performed a full failed `&amp;` scan over the entire remaining buffer before locating the nearby `;`. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk.</p> <p>An attacker can submit a small crafted body of the form `a;a;a;...` and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes.</p> <p>### Details</p> <p>In `python_multipart/multipart.py`, both the `FIELD_NAME` and `FIELD_DATA` states located the next separator like this:</p> <p>```python sep_pos = data.find(b&#34;&amp;&#34;, i) if sep_pos == -1: sep_pos = data.find(b&#34;;&#34;, i) ```</p> <p>`data.find(b&#34;&amp;&#34;, i)` scans from `i` to the end of the buffer and returns `-1` only when there is no `&amp;` anywhere in the remainder. For a `;` separated body with no `&amp;`, this failed full buffer scan repeats once per field, making parsing quadratic in the body length.</p> <p>For example, a 1 MiB url encoded body consisting of `a;` repeated ~500,000 times, submitted with `Content-Type: application/x-www-form-urlencoded`, causes the parser to perform on the order of 10^11 byte comparisons, consuming several seconds of C…</p> <p><strong>Affected:</strong> Homebrew: cycode</p> <p>### Summary</p> <p>When parsing `application/x-www-form-urlencoded` bodies, `QuerystringParser` located the field separator with a two step lookup: it first scanned the entire remaining buffer for `&amp;`, and only when no `&amp;` existed anywhere ahead did it fall back to scanning for `;`. For a body that uses `;` as the separator and contains no `&amp;`, every field iteration performed a full failed `&amp;` scan over the entire remaining buffer before locating the nearby `;`. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk.</p> <p>An attacker can submit a small crafted body of the form `a;a;a;...` and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes.</p> <p>### Details</p> <p>In `python_multipart/multipart.py`, both the `FIELD_NAME` and `FIELD_DATA` states located the next separator like this:</p> <p>```python sep_pos = data.find(b&#34;&amp;&#34;, i) if sep_pos == -1: sep_pos = data.find(b&#34;;&#34;, i) ```</p> <p>`data.find(b&#34;&amp;&#34;, i)` scans from `i` to the end of the buffer and returns `-1` only when there is no `&amp;` anywhere in the remainder. For a `;` separated body with no `&amp;`, this failed full buffer scan repeats once per field, making parsing quadratic in the body length.</p> <p>For example, a 1 MiB url encoded body consisting of `a;` repeated ~500,000 times, submitted with `Content-Type: application/x-www-form-urlencoded`, causes the parser to perform on the order of 10^11 byte comparisons, consuming several seconds of C…</p> https://cve.radiocsirt.org/vuln/brew-cycode-cve-2026-53539 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933 certfr-2026-avi-0933 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933 https://cve.radiocsirt.org/vuln/cleanstart-2026-eb34508 <p><strong>Affected:</strong> CleanStart: kserve-storage-controller, CleanStart: litellm-database</p> <p>CVE-2026-53539 affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Affected:</strong> CleanStart: kserve-storage-controller, CleanStart: litellm-database</p> <p>CVE-2026-53539 affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-eb34508 https://cve.radiocsirt.org/vuln/euvd-2026-329313 EUVD-2026-329313 https://cve.radiocsirt.org/vuln/euvd-2026-329313 https://cve.radiocsirt.org/vuln/fkie_cve-2026-53539 <p>Python-Multipart is a streaming multipart parser for Python. Prior to 0.0.30, when parsing application/x-www-form-urlencoded bodies, QuerystringParser located the field separator with a two step lookup: it first scanned the entire remaining buffer for &amp;, and only when no &amp; existed anywhere ahead did it fall back to scanning for ;. For a body that uses ; as the separator and contains no &amp;, every field iteration performed a full failed &amp; scan over the entire remaining buffer before locating the nearby ;. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk. An attacker can submit a small crafted body of the form a;a;a;... and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes. This vulnerability is fixed in 0.0.30.</p> <p>Python-Multipart is a streaming multipart parser for Python. Prior to 0.0.30, when parsing application/x-www-form-urlencoded bodies, QuerystringParser located the field separator with a two step lookup: it first scanned the entire remaining buffer for &amp;, and only when no &amp; existed anywhere ahead did it fall back to scanning for ;. For a body that uses ; as the separator and contains no &amp;, every field iteration performed a full failed &amp; scan over the entire remaining buffer before locating the nearby ;. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk. An attacker can submit a small crafted body of the form a;a;a;... and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes. This vulnerability is fixed in 0.0.30.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-53539 https://cve.radiocsirt.org/vuln/ghsa-5rvq-cxj2-64vf <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>When parsing `application/x-www-form-urlencoded` bodies, `QuerystringParser` located the field separator with a two step lookup: it first scanned the entire remaining buffer for `&amp;`, and only when no `&amp;` existed anywhere ahead did it fall back to scanning for `;`. For a body that uses `;` as the separator and contains no `&amp;`, every field iteration performed a full failed `&amp;` scan over the entire remaining buffer before locating the nearby `;`. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk.</p> <p>An attacker can submit a small crafted body of the form `a;a;a;...` and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes.</p> <p>### Details</p> <p>In `python_multipart/multipart.py`, both the `FIELD_NAME` and `FIELD_DATA` states located the next separator like this:</p> <p>```python sep_pos = data.find(b&#34;&amp;&#34;, i) if sep_pos == -1: sep_pos = data.find(b&#34;;&#34;, i) ```</p> <p>`data.find(b&#34;&amp;&#34;, i)` scans from `i` to the end of the buffer and returns `-1` only when there is no `&amp;` anywhere in the remainder. For a `;` separated body with no `&amp;`, this failed full buffer scan repeats once per field, making parsing quadratic in the body length.</p> <p>For example, a 1 MiB url encoded body consisting of `a;` repeated ~500,000 times, submitted with `Content-Type: application/x-www-form-urlencoded`, causes the parser to perform on the order of 10^11 byte comparisons, consuming several seconds of C…</p> <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>When parsing `application/x-www-form-urlencoded` bodies, `QuerystringParser` located the field separator with a two step lookup: it first scanned the entire remaining buffer for `&amp;`, and only when no `&amp;` existed anywhere ahead did it fall back to scanning for `;`. For a body that uses `;` as the separator and contains no `&amp;`, every field iteration performed a full failed `&amp;` scan over the entire remaining buffer before locating the nearby `;`. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk.</p> <p>An attacker can submit a small crafted body of the form `a;a;a;...` and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes.</p> <p>### Details</p> <p>In `python_multipart/multipart.py`, both the `FIELD_NAME` and `FIELD_DATA` states located the next separator like this:</p> <p>```python sep_pos = data.find(b&#34;&amp;&#34;, i) if sep_pos == -1: sep_pos = data.find(b&#34;;&#34;, i) ```</p> <p>`data.find(b&#34;&amp;&#34;, i)` scans from `i` to the end of the buffer and returns `-1` only when there is no `&amp;` anywhere in the remainder. For a `;` separated body with no `&amp;`, this failed full buffer scan repeats once per field, making parsing quadratic in the body length.</p> <p>For example, a 1 MiB url encoded body consisting of `a;` repeated ~500,000 times, submitted with `Content-Type: application/x-www-form-urlencoded`, causes the parser to perform on the order of 10^11 byte comparisons, consuming several seconds of C…</p> https://cve.radiocsirt.org/vuln/ghsa-5rvq-cxj2-64vf https://cve.radiocsirt.org/vuln/opensuse-su-2026:21066-1 <p>Security update for python-python-multipart</p> <p>Security update for python-python-multipart</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:21066-1 https://cve.radiocsirt.org/vuln/pysec-2026-3036 <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>When parsing `application/x-www-form-urlencoded` bodies, `QuerystringParser` located the field separator with a two step lookup: it first scanned the entire remaining buffer for `&amp;`, and only when no `&amp;` existed anywhere ahead did it fall back to scanning for `;`. For a body that uses `;` as the separator and contains no `&amp;`, every field iteration performed a full failed `&amp;` scan over the entire remaining buffer before locating the nearby `;`. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk.</p> <p>An attacker can submit a small crafted body of the form `a;a;a;...` and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes.</p> <p>### Details</p> <p>In `python_multipart/multipart.py`, both the `FIELD_NAME` and `FIELD_DATA` states located the next separator like this:</p> <p>```python sep_pos = data.find(b&#34;&amp;&#34;, i) if sep_pos == -1: sep_pos = data.find(b&#34;;&#34;, i) ```</p> <p>`data.find(b&#34;&amp;&#34;, i)` scans from `i` to the end of the buffer and returns `-1` only when there is no `&amp;` anywhere in the remainder. For a `;` separated body with no `&amp;`, this failed full buffer scan repeats once per field, making parsing quadratic in the body length.</p> <p>For example, a 1 MiB url encoded body consisting of `a;` repeated ~500,000 times, submitted with `Content-Type: application/x-www-form-urlencoded`, causes the parser to perform on the order of 10^11 byte comparisons, consuming several seconds of C…</p> <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>When parsing `application/x-www-form-urlencoded` bodies, `QuerystringParser` located the field separator with a two step lookup: it first scanned the entire remaining buffer for `&amp;`, and only when no `&amp;` existed anywhere ahead did it fall back to scanning for `;`. For a body that uses `;` as the separator and contains no `&amp;`, every field iteration performed a full failed `&amp;` scan over the entire remaining buffer before locating the nearby `;`. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk.</p> <p>An attacker can submit a small crafted body of the form `a;a;a;...` and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes.</p> <p>### Details</p> <p>In `python_multipart/multipart.py`, both the `FIELD_NAME` and `FIELD_DATA` states located the next separator like this:</p> <p>```python sep_pos = data.find(b&#34;&amp;&#34;, i) if sep_pos == -1: sep_pos = data.find(b&#34;;&#34;, i) ```</p> <p>`data.find(b&#34;&amp;&#34;, i)` scans from `i` to the end of the buffer and returns `-1` only when there is no `&amp;` anywhere in the remainder. For a `;` separated body with no `&amp;`, this failed full buffer scan repeats once per field, making parsing quadratic in the body length.</p> <p>For example, a 1 MiB url encoded body consisting of `a;` repeated ~500,000 times, submitted with `Content-Type: application/x-www-form-urlencoded`, causes the parser to perform on the order of 10^11 byte comparisons, consuming several seconds of C…</p> https://cve.radiocsirt.org/vuln/pysec-2026-3036 https://cve.radiocsirt.org/vuln/suse-su-2026:22372-1 <p>Security update for python-python-multipart</p> <p>Security update for python-python-multipart</p> https://cve.radiocsirt.org/vuln/suse-su-2026:22372-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53539 <p><strong>Affected:</strong> Ubuntu:Pro:22.04:LTS: python-multipart, Ubuntu:Pro:24.04:LTS: python-multipart, Ubuntu:25.10: python-multipart, Ubuntu:26.04:LTS: python-multipart</p> <p>Python-Multipart is a streaming multipart parser for Python. Prior to 0.0.30, when parsing application/x-www-form-urlencoded bodies, QuerystringParser located the field separator with a two step lookup: it first scanned the entire remaining buffer for &amp;, and only when no &amp; existed anywhere ahead did it fall back to scanning for ;. For a body that uses ; as the separator and contains no &amp;, every field iteration performed a full failed &amp; scan over the entire remaining buffer before locating the nearby ;. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk. An attacker can submit a small crafted body of the form a;a;a;... and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes. This vulnerability is fixed in 0.0.30.</p> <p><strong>Affected:</strong> Ubuntu:Pro:22.04:LTS: python-multipart, Ubuntu:Pro:24.04:LTS: python-multipart, Ubuntu:25.10: python-multipart, Ubuntu:26.04:LTS: python-multipart</p> <p>Python-Multipart is a streaming multipart parser for Python. Prior to 0.0.30, when parsing application/x-www-form-urlencoded bodies, QuerystringParser located the field separator with a two step lookup: it first scanned the entire remaining buffer for &amp;, and only when no &amp; existed anywhere ahead did it fall back to scanning for ;. For a body that uses ; as the separator and contains no &amp;, every field iteration performed a full failed &amp; scan over the entire remaining buffer before locating the nearby ;. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk. An attacker can submit a small crafted body of the form a;a;a;... and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes. This vulnerability is fixed in 0.0.30.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53539