Affected: Homebrew: cycode

### Summary

`QuerystringParser` treated `;` as a field separator in `application/x-www-form-urlencoded` bodies, in addition to `&`. The [WHATWG URL standard](https://url.spec.whatwg.org/#urlencoded-parsing), modern browsers, and Python's `urllib.parse` (since the CVE-2021-23336 fix) treat only `&` as a separator. This creates a parser differential: the same bytes are tokenized into different fields than a WHATWG compliant intermediary would produce, allowing an attacker to smuggle extra form fields past an upstream body inspecting component.

### Details

In `python_multipart/multipart.py`, the `FIELD_NAME` and `FIELD_DATA` states located the next separator by scanning for `&` and, failing that, for `;`:

```python sep_pos = data.find(b"&", i) if sep_pos == -1: sep_pos = data.find(b";", i) ```

As a result, `;` acted as a field boundary. Because the fallback only triggered when no `&` remained in the current chunk, tokenization also depended on unrelated bytes later in the buffer and on how the body was split across `write()` calls. This is the same class of issue as CVE-2021-23336 in CPython's `urllib.parse`.

For example, a body inspecting WAF or gateway that follows the WHATWG rule (only `&` separates fields) receives:

``` role=user&x=;role=admin ```

The upstream parses two fields, `role=user` and `x=";role=admin"`, sees a benign `role=user`, and forwards the request. `QuerystringParser` parsed the same bytes as three fields: `role="user"`, `x=""`, and `role="admin…

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, QuerystringParser treated ; as a field separator in application/x-www-form-urlencoded bodies, in addition to &. The WHATWG URL standard, modern browsers, and Python's urllib.parse (since the CVE-2021-23336 fix) treat only & as a separator. This creates a parser differential: the same bytes are tokenized into different fields than a WHATWG compliant intermediary would produce, allowing an attacker to smuggle extra form fields past an upstream body inspecting component. This vulnerability is fixed in 0.0.30.

Affected: PyPI: python-multipart

### Summary

`QuerystringParser` treated `;` as a field separator in `application/x-www-form-urlencoded` bodies, in addition to `&`. The [WHATWG URL standard](https://url.spec.whatwg.org/#urlencoded-parsing), modern browsers, and Python's `urllib.parse` (since the CVE-2021-23336 fix) treat only `&` as a separator. This creates a parser differential: the same bytes are tokenized into different fields than a WHATWG compliant intermediary would produce, allowing an attacker to smuggle extra form fields past an upstream body inspecting component.

### Details

In `python_multipart/multipart.py`, the `FIELD_NAME` and `FIELD_DATA` states located the next separator by scanning for `&` and, failing that, for `;`:

```python sep_pos = data.find(b"&", i) if sep_pos == -1: sep_pos = data.find(b";", i) ```

As a result, `;` acted as a field boundary. Because the fallback only triggered when no `&` remained in the current chunk, tokenization also depended on unrelated bytes later in the buffer and on how the body was split across `write()` calls. This is the same class of issue as CVE-2021-23336 in CPython's `urllib.parse`.

For example, a body inspecting WAF or gateway that follows the WHATWG rule (only `&` separates fields) receives:

``` role=user&x=;role=admin ```

The upstream parses two fields, `role=user` and `x=";role=admin"`, sees a benign `role=user`, and forwards the request. `QuerystringParser` parsed the same bytes as three fields: `role="user"`, `x=""`, and `role="admin…

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

Affected: PyPI: python-multipart

### Summary

`QuerystringParser` treated `;` as a field separator in `application/x-www-form-urlencoded` bodies, in addition to `&`. The [WHATWG URL standard](https://url.spec.whatwg.org/#urlencoded-parsing), modern browsers, and Python's `urllib.parse` (since the CVE-2021-23336 fix) treat only `&` as a separator. This creates a parser differential: the same bytes are tokenized into different fields than a WHATWG compliant intermediary would produce, allowing an attacker to smuggle extra form fields past an upstream body inspecting component.

### Details

In `python_multipart/multipart.py`, the `FIELD_NAME` and `FIELD_DATA` states located the next separator by scanning for `&` and, failing that, for `;`:

```python sep_pos = data.find(b"&", i) if sep_pos == -1: sep_pos = data.find(b";", i) ```

As a result, `;` acted as a field boundary. Because the fallback only triggered when no `&` remained in the current chunk, tokenization also depended on unrelated bytes later in the buffer and on how the body was split across `write()` calls. This is the same class of issue as CVE-2021-23336 in CPython's `urllib.parse`.

For example, a body inspecting WAF or gateway that follows the WHATWG rule (only `&` separates fields) receives:

``` role=user&x=;role=admin ```

The upstream parses two fields, `role=user` and `x=";role=admin"`, sees a benign `role=user`, and forwards the request. `QuerystringParser` parsed the same bytes as three fields: `role="user"`, `x=""`, and `role="admin…

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, QuerystringParser treated ; as a field separator in application/x-www-form-urlencoded bodies, in addition to &. The WHATWG URL standard, modern browsers, and Python's urllib.parse (since the CVE-2021-23336 fix) treat only & as a separator. This creates a parser differential: the same bytes are tokenized into different fields than a WHATWG compliant intermediary would produce, allowing an attacker to smuggle extra form fields past an upstream body inspecting component. This vulnerability is fixed in 0.0.30.