Affected: Homebrew: bump-my-version

### Summary

HTTPX2 serializes the per-file `Content-Type` and custom headers supplied through the `files=` tuple API directly into the `multipart/form-data` body without validating custom header names or values. An attacker who can influence upload metadata passed to HTTPX2 can use CR or LF characters to terminate a multipart part header and inject additional part headers or end the part header block early.

### Details

The three-element file tuple accepts `(filename, content, content_type)`, and the four-element form accepts `(filename, content, content_type, headers)`. `FileField.render_headers()` interpolates the supplied header names and values between CRLF delimiters without validating them.

For example:

```python import httpx2

request = httpx2.Request( "POST", "https://example.com/upload", headers={"Content-Type": "multipart/form-data; boundary=BOUNDARY"}, files={ "file": ( "safe.txt", b"payload", "text/plain\r\nX-Injected: true", ) }, )

print(request.read().decode()) ```

The generated body contains an attacker-injected part header:

```text --BOUNDARY Content-Disposition: form-data; name="file"; filename="safe.txt" Content-Type: text/plain X-Injected: true

payload --BOUNDARY-- ```

The same issue affects names and values in the custom header mapping from the four-element tuple.

Field names and filenames are serialized through a separate escaping path and do not permit CRLF header injectio…

Affected: pydantic httpx2

HTTPX2 is a next generation HTTP client for Python. Prior to 2.11.0, FileField.render_headers() in src/httpx2/httpx2/_multipart.py directly interpolates attacker-controlled content_type values and custom headers from the files= three-element (filename, content, content_type) tuple and the files= four-element (filename, content, content_type, headers) tuple into multipart/form-data part headers without validating header names or values. CR or LF characters can terminate a part header, inject additional part headers, or end the part header block early, allowing a downstream multipart parser to treat attacker-supplied lines as genuine headers and potentially alter part semantics or bypass header-based checks. This issue is fixed in version 2.11.0.

Affected: PyPI: httpx2

### Summary

HTTPX2 serializes the per-file `Content-Type` and custom headers supplied through the `files=` tuple API directly into the `multipart/form-data` body without validating custom header names or values. An attacker who can influence upload metadata passed to HTTPX2 can use CR or LF characters to terminate a multipart part header and inject additional part headers or end the part header block early.

### Details

The three-element file tuple accepts `(filename, content, content_type)`, and the four-element form accepts `(filename, content, content_type, headers)`. `FileField.render_headers()` interpolates the supplied header names and values between CRLF delimiters without validating them.

For example:

```python import httpx2

request = httpx2.Request( "POST", "https://example.com/upload", headers={"Content-Type": "multipart/form-data; boundary=BOUNDARY"}, files={ "file": ( "safe.txt", b"payload", "text/plain\r\nX-Injected: true", ) }, )

print(request.read().decode()) ```

The generated body contains an attacker-injected part header:

```text --BOUNDARY Content-Disposition: form-data; name="file"; filename="safe.txt" Content-Type: text/plain X-Injected: true

payload --BOUNDARY-- ```

The same issue affects names and values in the custom header mapping from the four-element tuple.

Field names and filenames are serialized through a separate escaping path and do not permit CRLF header injectio…