Threat Intelligence Database

Starlette, a Python web framework used by applications such as Glances and FastAPI, has a denial of service (DoS) vulnerability (CVE-2024-47874) related to handling multipart/form-data requests. Specifically, Starlette treats multipart form parts without a filename as text fields and buffers them in memory without size limits. This can be exploited by attackers to upload arbitrarily large form fields, causing excessive memory consumption and server slowdown or crash due to out-of-memory conditions. The vulnerability affects all applications built with Starlette or FastAPI that accept form requests. A patch is available to address this issue.

Starlette, a Python web framework used by pieces-cli and Glances, has a denial-of-service vulnerability (CVE-2025-54121) when parsing multipart forms with large file uploads. The vulnerability causes the main event thread to block during rollover of large files to disk, preventing new connections from being accepted. The impact is rated medium with a CVSS score of 5.3 and primarily affects systems with slower disk I/O. A patch is available to address this issue.

A vulnerability in mcpm's Starlette component allows an attacker to manipulate the reconstructed request URL's hostname by sending a request path that does not start with a slash. This causes the URL parser to misinterpret the path as part of the authority section, leading to an attacker-controlled hostname in request.url.hostname. This can mislead code that relies on request.url.hostname for security decisions. The issue affects versions where the request path is not validated before URL reconstruction. A patch is available that prevents the path from crossing into the URL authority.

Starlette versions prior to 1.3.0 contain a vulnerability where the HTTP request path is not properly validated before being used to reconstruct the request URL. This flaw allows an attacker to supply a request path that does not start with a slash, causing the URL parser to misinterpret the path as part of the hostname. This can lead to an attacker-controlled hostname in request.url.hostname, potentially misleading security-sensitive logic relying on this value. The vulnerability is addressed by upgrading to a fixed version that correctly validates and reconstructs the URL.

Pallets Click versions 8.3.2 and below contain a command injection vulnerability in the click.edit() function. This flaw allows attackers to execute arbitrary operating system commands from an unprivileged account. A security update addressing this issue is available. The vulnerability has been rated with medium severity. There are no known exploits in the wild at this time.

Starlette versions 1.0.1 and below have a vulnerability in HTTPEndpoint where arbitrary HTTP methods can invoke unintended internal methods if routes are registered without explicit HTTP method constraints. This affects applications using HTTPEndpoint subclasses via Route(...) without specifying allowed methods, potentially impacting frameworks built on Starlette such as FastAPI. The vulnerability has a medium severity with a CVSS score of 5.3.

### Summary In affected versions, the HTTP `Host` request header was not validated before being used to reconstruct `request.url`. Because the routing algorithm relies on the raw HTTP path while `request.url` is rebuilt from the `Host` header, a malformed header could make `request.url.path` differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on `request.url` (rather than the raw `scope` path) could therefore be bypassed. ### Details When a client requests `http://example.com/foo`, it sends: ```http GET /foo HTTP/1.1 Host: example.com ``` Affected versions reconstructed the URL by concatenating `http://{host}{path}` and re-parsing the result. The `Host` value is only valid as a `uri-host [ ":" port ]` per [RFC 9112 §3.2](https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2-6), where `uri-host` follows the restricted `host` grammar of [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2). When it contains characters outside that grammar - notably `/`, `?`, or `#` - those characters move the path/query/fragment boundaries during re-parsing, so the parsed `request.url.path` no longer matches the path the server actually received. For example: ```http GET /foo HTTP/1.1 Host: example.com/abc?bar= ``` reconstructs to `http://example.com/abc?bar=/foo`, whose parsed `path` is `/abc` - even though routing used the real path `/foo`. The router still dispatches to `/foo` and the endpoint executes, but any middleware or code that reads `request.url.path` sees `/abc`, so path-based authorization checks can be bypassed. ### Impact Any application running an affected version that relies on `request.url` (or `request.url.path`) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on `request.url.path`. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed `Host` header before forwarding and the application does not trust attacker-controlled host headers (e.g. `X-Forwarded-Host`) elsewhere. ### Mitigation Upgrade to a patched version, which validates the `Host` header against the grammar of [RFC 9112 §3.2](https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2-6) / [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2) when constructing `request.url` and falls back to `scope["server"]` for malformed values.