https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 02:47:43 +0000 https://cve.radiocsirt.org/vuln/brew-cycode-cve-2026-53537 <p><strong>Affected:</strong> Homebrew: cycode</p> <p>### Summary</p> <p>`parse_options_header` parsed `Content-Disposition` (and `Content-Type`) headers with [`email.message.Message`](https://docs.python.org/3/library/email.compat32-message.html#email.message.Message), which transparently applies [RFC 2231](https://datatracker.ietf.org/doc/html/rfc2231)/[5987](https://datatracker.ietf.org/doc/html/rfc5987) decoding. The extended parameter syntax (`filename*=charset&#39;lang&#39;value`, `name*=...`, and the `filename*0`/`filename*1` continuation form) is decoded and surfaced under the bare `filename`/`name` key, and overrides the plain parameter when both are present. [RFC 7578 §4.2](https://datatracker.ietf.org/doc/html/rfc7578#section-4.2) explicitly forbids the `filename*` form in `multipart/form-data`.</p> <p>Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for `multipart/form-data` (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend.</p> <p>### Details</p> <p>Given both a plain and an extended parameter, the extended value won. For example:</p> <p>``` Content-Disposition: form-data; name=&#34;comment&#34;; name*=utf-8&#39;&#39;role ```</p> <p>An inspector following RFC 7578 sees the field `comment`, while the returned value was `name=role`. The same applies to filenames:</p> <p>``` Content-Disposition: form-data; name=&#34;upload&#34;; filename=&#34;safe.txt&#34;; filename*=utf-8&#39;&#39;evil.php ```</p> <p>The inspector sees `safe.txt`, while…</p> <p><strong>Affected:</strong> Homebrew: cycode</p> <p>### Summary</p> <p>`parse_options_header` parsed `Content-Disposition` (and `Content-Type`) headers with [`email.message.Message`](https://docs.python.org/3/library/email.compat32-message.html#email.message.Message), which transparently applies [RFC 2231](https://datatracker.ietf.org/doc/html/rfc2231)/[5987](https://datatracker.ietf.org/doc/html/rfc5987) decoding. The extended parameter syntax (`filename*=charset&#39;lang&#39;value`, `name*=...`, and the `filename*0`/`filename*1` continuation form) is decoded and surfaced under the bare `filename`/`name` key, and overrides the plain parameter when both are present. [RFC 7578 §4.2](https://datatracker.ietf.org/doc/html/rfc7578#section-4.2) explicitly forbids the `filename*` form in `multipart/form-data`.</p> <p>Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for `multipart/form-data` (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend.</p> <p>### Details</p> <p>Given both a plain and an extended parameter, the extended value won. For example:</p> <p>``` Content-Disposition: form-data; name=&#34;comment&#34;; name*=utf-8&#39;&#39;role ```</p> <p>An inspector following RFC 7578 sees the field `comment`, while the returned value was `name=role`. The same applies to filenames:</p> <p>``` Content-Disposition: form-data; name=&#34;upload&#34;; filename=&#34;safe.txt&#34;; filename*=utf-8&#39;&#39;evil.php ```</p> <p>The inspector sees `safe.txt`, while…</p> https://cve.radiocsirt.org/vuln/brew-cycode-cve-2026-53537 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-eh47852 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: litellm-database</p> <p>Multiple security vulnerabilities affect the litellm-database package. These issues are resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: litellm-database</p> <p>Multiple security vulnerabilities affect the litellm-database package. These issues are resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-eh47852 https://cve.radiocsirt.org/vuln/euvd-2026-329311 EUVD-2026-329311 https://cve.radiocsirt.org/vuln/euvd-2026-329311 https://cve.radiocsirt.org/vuln/fkie_cve-2026-53537 <p>Python-Multipart is a streaming multipart parser for Python. Prior to 0.0.30, parse_options_header parsed Content-Disposition (and Content-Type) headers with email.message.Message, which transparently applies RFC 2231/5987 decoding. The extended parameter syntax (filename*=charset&#39;lang&#39;value, name*=..., and the filename*0/filename*1 continuation form) is decoded and surfaced under the bare filename/name key, and overrides the plain parameter when both are present. RFC 7578 §4.2 explicitly forbids the filename* form in multipart/form-data. Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for multipart/form-data (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend. This vulnerability is fixed in 0.0.30.</p> <p>Python-Multipart is a streaming multipart parser for Python. Prior to 0.0.30, parse_options_header parsed Content-Disposition (and Content-Type) headers with email.message.Message, which transparently applies RFC 2231/5987 decoding. The extended parameter syntax (filename*=charset&#39;lang&#39;value, name*=..., and the filename*0/filename*1 continuation form) is decoded and surfaced under the bare filename/name key, and overrides the plain parameter when both are present. RFC 7578 §4.2 explicitly forbids the filename* form in multipart/form-data. Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for multipart/form-data (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend. This vulnerability is fixed in 0.0.30.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-53537 https://cve.radiocsirt.org/vuln/ghsa-vffw-93wf-4j4q <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>`parse_options_header` parsed `Content-Disposition` (and `Content-Type`) headers with [`email.message.Message`](https://docs.python.org/3/library/email.compat32-message.html#email.message.Message), which transparently applies [RFC 2231](https://datatracker.ietf.org/doc/html/rfc2231)/[5987](https://datatracker.ietf.org/doc/html/rfc5987) decoding. The extended parameter syntax (`filename*=charset&#39;lang&#39;value`, `name*=...`, and the `filename*0`/`filename*1` continuation form) is decoded and surfaced under the bare `filename`/`name` key, and overrides the plain parameter when both are present. [RFC 7578 §4.2](https://datatracker.ietf.org/doc/html/rfc7578#section-4.2) explicitly forbids the `filename*` form in `multipart/form-data`.</p> <p>Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for `multipart/form-data` (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend.</p> <p>### Details</p> <p>Given both a plain and an extended parameter, the extended value won. For example:</p> <p>``` Content-Disposition: form-data; name=&#34;comment&#34;; name*=utf-8&#39;&#39;role ```</p> <p>An inspector following RFC 7578 sees the field `comment`, while the returned value was `name=role`. The same applies to filenames:</p> <p>``` Content-Disposition: form-data; name=&#34;upload&#34;; filename=&#34;safe.txt&#34;; filename*=utf-8&#39;&#39;evil.php ```</p> <p>The inspector sees `safe.txt`, while…</p> <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>`parse_options_header` parsed `Content-Disposition` (and `Content-Type`) headers with [`email.message.Message`](https://docs.python.org/3/library/email.compat32-message.html#email.message.Message), which transparently applies [RFC 2231](https://datatracker.ietf.org/doc/html/rfc2231)/[5987](https://datatracker.ietf.org/doc/html/rfc5987) decoding. The extended parameter syntax (`filename*=charset&#39;lang&#39;value`, `name*=...`, and the `filename*0`/`filename*1` continuation form) is decoded and surfaced under the bare `filename`/`name` key, and overrides the plain parameter when both are present. [RFC 7578 §4.2](https://datatracker.ietf.org/doc/html/rfc7578#section-4.2) explicitly forbids the `filename*` form in `multipart/form-data`.</p> <p>Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for `multipart/form-data` (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend.</p> <p>### Details</p> <p>Given both a plain and an extended parameter, the extended value won. For example:</p> <p>``` Content-Disposition: form-data; name=&#34;comment&#34;; name*=utf-8&#39;&#39;role ```</p> <p>An inspector following RFC 7578 sees the field `comment`, while the returned value was `name=role`. The same applies to filenames:</p> <p>``` Content-Disposition: form-data; name=&#34;upload&#34;; filename=&#34;safe.txt&#34;; filename*=utf-8&#39;&#39;evil.php ```</p> <p>The inspector sees `safe.txt`, while…</p> https://cve.radiocsirt.org/vuln/ghsa-vffw-93wf-4j4q https://cve.radiocsirt.org/vuln/opensuse-su-2026:11099-1 <p>python311-python-multipart-0.0.32-1.1 on GA media</p> <p>python311-python-multipart-0.0.32-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11099-1 https://cve.radiocsirt.org/vuln/pysec-2026-3041 <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>`parse_options_header` parsed `Content-Disposition` (and `Content-Type`) headers with [`email.message.Message`](https://docs.python.org/3/library/email.compat32-message.html#email.message.Message), which transparently applies [RFC 2231](https://datatracker.ietf.org/doc/html/rfc2231)/[5987](https://datatracker.ietf.org/doc/html/rfc5987) decoding. The extended parameter syntax (`filename*=charset&#39;lang&#39;value`, `name*=...`, and the `filename*0`/`filename*1` continuation form) is decoded and surfaced under the bare `filename`/`name` key, and overrides the plain parameter when both are present. [RFC 7578 §4.2](https://datatracker.ietf.org/doc/html/rfc7578#section-4.2) explicitly forbids the `filename*` form in `multipart/form-data`.</p> <p>Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for `multipart/form-data` (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend.</p> <p>### Details</p> <p>Given both a plain and an extended parameter, the extended value won. For example:</p> <p>``` Content-Disposition: form-data; name=&#34;comment&#34;; name*=utf-8&#39;&#39;role ```</p> <p>An inspector following RFC 7578 sees the field `comment`, while the returned value was `name=role`. The same applies to filenames:</p> <p>``` Content-Disposition: form-data; name=&#34;upload&#34;; filename=&#34;safe.txt&#34;; filename*=utf-8&#39;&#39;evil.php ```</p> <p>The inspector sees `safe.txt`, while…</p> <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>`parse_options_header` parsed `Content-Disposition` (and `Content-Type`) headers with [`email.message.Message`](https://docs.python.org/3/library/email.compat32-message.html#email.message.Message), which transparently applies [RFC 2231](https://datatracker.ietf.org/doc/html/rfc2231)/[5987](https://datatracker.ietf.org/doc/html/rfc5987) decoding. The extended parameter syntax (`filename*=charset&#39;lang&#39;value`, `name*=...`, and the `filename*0`/`filename*1` continuation form) is decoded and surfaced under the bare `filename`/`name` key, and overrides the plain parameter when both are present. [RFC 7578 §4.2](https://datatracker.ietf.org/doc/html/rfc7578#section-4.2) explicitly forbids the `filename*` form in `multipart/form-data`.</p> <p>Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for `multipart/form-data` (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend.</p> <p>### Details</p> <p>Given both a plain and an extended parameter, the extended value won. For example:</p> <p>``` Content-Disposition: form-data; name=&#34;comment&#34;; name*=utf-8&#39;&#39;role ```</p> <p>An inspector following RFC 7578 sees the field `comment`, while the returned value was `name=role`. The same applies to filenames:</p> <p>``` Content-Disposition: form-data; name=&#34;upload&#34;; filename=&#34;safe.txt&#34;; filename*=utf-8&#39;&#39;evil.php ```</p> <p>The inspector sees `safe.txt`, while…</p> https://cve.radiocsirt.org/vuln/pysec-2026-3041 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-53537 <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, parse_options_header parsed Content-Disposition (and Content-Type) headers with email.message.Message, which transparently applies RFC 2231/5987 decoding. The extended parameter syntax (filename*=charset&#39;lang&#39;value, name*=..., and the filename*0/filename*1 continuation form) is decoded and surfaced under the bare filename/name key, and overrides the plain parameter when both are present. RFC 7578 §4.2 explicitly forbids the filename* form in multipart/form-data. Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for multipart/form-data (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend. 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, parse_options_header parsed Content-Disposition (and Content-Type) headers with email.message.Message, which transparently applies RFC 2231/5987 decoding. The extended parameter syntax (filename*=charset&#39;lang&#39;value, name*=..., and the filename*0/filename*1 continuation form) is decoded and surfaced under the bare filename/name key, and overrides the plain parameter when both are present. RFC 7578 §4.2 explicitly forbids the filename* form in multipart/form-data. Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for multipart/form-data (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend. This vulnerability is fixed in 0.0.30.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53537