https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 11:21:17 +0000 https://db.gcve.eu/vuln/cve-2026-53537 <p><strong>Affected:</strong> Kludex 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> Kludex 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://db.gcve.eu/vuln/cve-2026-53537 https://db.gcve.eu/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://db.gcve.eu/vuln/ghsa-vffw-93wf-4j4q https://db.gcve.eu/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://db.gcve.eu/vuln/pysec-2026-3041