Sammiee5311

The software does not consistently enforce the expiry and single-use requirement of OAuth2 authorization codes during the token exchange process. OAuth2 is a standard for access delegation, allowing third-party applications to obtain limited access to an HTTP service.

The `parse options header` function parsed `Content-Disposition` and `Content-Type` headers using `email.message.Message`, which applies RFC 2231/5987 decoding. This allows extended parameter syntax, such as `filename*`, `name*`, and continuation forms (`filename*0`, `filename*1`), to override plain parameters when both are present. However, RFC 7578 §4.2 explicitly forbids the `filename*` form in `multipart/form-data`. This creates an interpretation conflict where upstream components (such as WAFs, proxies, or gateways) that follow RFC 7578 or do not implement RFC 2231/5987 decoding may interpret headers differently than the backend. An attacker can exploit this to smuggle a different field name or filename past an inspector. This affects the `parse options header`, `FormParser`, `create form parser`, and `parse form` APIs, and impacts Starlette/FastAPI via `request.form()`, exposing smuggled values as form field names or `UploadFile.filename`. Potential consequences include bypassing access or upload controls based on field names or filenames, and path traversal if the application builds filesystem paths from the parsed filename without sanitization, as percent-encoded sequences like `..%2F` are decoded.

An issue exists in the curl-based transport backend where credentials may be leaked to attacker-controlled servers following HTTP redirects. This occurs because the credential validation process verifies the original URL rather than the effective URL after the redirect has taken place. Consequently, attackers can steal authentication tokens by utilizing cross-domain redirects or HTTPS-to-HTTP downgrades.

The `vars regexp` matcher in Caddy double-expands user-controlled input through the Caddy replacer. When `vars regexp` matches a placeholder like `{http.request.header.X-Input}`, the header value is resolved and then re-evaluated, allowing an attacker to inject placeholders like `{env.DATABASE URL}` or `{file./etc/passwd}` into a request header and potentially leak environment variables, file contents, and system information. This issue stems from a code-level inconsistency where `vars regexp` includes an unnecessary second expansion step not present in `header regexp` and `path regexp`. The issue was introduced by a fix intended to resolve placeholder keys. An attacker can exploit this by crafting requests with malicious headers, leading to information disclosure. The vulnerability allows access to environment variables, file contents (up to 1MB), and system information such as hostname and operating system details.