Affected: Homebrew: cycode

### Summary

`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'lang'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`.

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.

### Details

Given both a plain and an extended parameter, the extended value won. For example:

``` Content-Disposition: form-data; name="comment"; name*=utf-8''role ```

An inspector following RFC 7578 sees the field `comment`, while the returned value was `name=role`. The same applies to filenames:

``` Content-Disposition: form-data; name="upload"; filename="safe.txt"; filename*=utf-8''evil.php ```

The inspector sees `safe.txt`, while…

Withdrawn by the publisher.

Affected: CleanStart: litellm-database

Multiple security vulnerabilities affect the litellm-database package. These issues are resolved in later releases. See references for individual vulnerability details.

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'lang'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.

Affected: PyPI: python-multipart

### Summary

`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'lang'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`.

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.

### Details

Given both a plain and an extended parameter, the extended value won. For example:

``` Content-Disposition: form-data; name="comment"; name*=utf-8''role ```

An inspector following RFC 7578 sees the field `comment`, while the returned value was `name=role`. The same applies to filenames:

``` Content-Disposition: form-data; name="upload"; filename="safe.txt"; filename*=utf-8''evil.php ```

The inspector sees `safe.txt`, while…

python311-python-multipart-0.0.32-1.1 on GA media

Affected: PyPI: python-multipart

### Summary

`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'lang'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`.

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.

### Details

Given both a plain and an extended parameter, the extended value won. For example:

``` Content-Disposition: form-data; name="comment"; name*=utf-8''role ```

An inspector following RFC 7578 sees the field `comment`, while the returned value was `name=role`. The same applies to filenames:

``` Content-Disposition: form-data; name="upload"; filename="safe.txt"; filename*=utf-8''evil.php ```

The inspector sees `safe.txt`, while…

Security update for python-python-multipart

Affected: 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

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'lang'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.