Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
request.form() accepts maxfields and maxpartsize to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. Details request.form() dispatches to a different parser depending on the Content-Type. For multipart/form-data the maxfiles, maxfields, and maxpartsize limits are forwarded to the parser, but for application/x-www-form-urlencoded the parser is constructed without them. It has no maxfields or maxpartsize parameter to receive them, and it appends every field with no count check and accumulates each field's name and value with no size check. The configured limits are therefore both unreachable and unenforced for url-encoded bodies. Because the url-encoded parser…
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions, the HTTP request path is not validated before being used to reconstruct request.url. Because request.url is rebuilt by concatenating {scheme}://{host}{path} and re-parsing the result, a path that does not begin with / (for example @google.com) moves the authority boundary during re-parsing, so request.url.hostname and request.url.netloc become attacker-controlled. Code that reads request.url.hostname (rather than the Host header or scope) can therefore be misled into trusting an attacker-supplied host. Details When a client requests a path that does not start with /: affected versions reconstruct the URL as http://localhost@google.com. Per RFC 3986 §3.2.1, the substring before @ in the authority is userinfo, so re-parsing yields username = "localhost" and hostname = "google.com", with an empty path: The root cause is that the path is concatenated directly after the host without a separating /, and without validating that it begins with one. Only the Host…
Recommended action: Upgrade to 1.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When serving static files on Windows, StaticFiles resolves the requested path with os.path.realpath. If a UNC path (such as \\attacker.com\share) reaches the resolver, realpath causes the process to open a connection to the remote host over SMB (port 445). This is a server-side request forgery (SSRF) that leaks the service account's NTLMv2 credentials to the attacker-controlled host, which can then be cracked offline or relayed to other hosts. Details StaticFiles.lookuppath() joins the requested path onto the served directory and calls os.path.realpath on the result before checking containment with os.path.commonpath. On Windows, a UNC path is absolute, so os.path.join discards the served directory and realpath resolves the bare UNC path, triggering the outbound SMB connection and NTLM authentication before the containment check rejects the path. The HTTP response is a benign 404, but the credential disclosure has already happened. POSIX systems are not affected. This only…
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When dispatching a request, HTTPEndpoint selects the handler by lowercasing the HTTP method and looking it up as an attribute with getattr, without restricting the lookup to a known set of HTTP verbs. When an HTTPEndpoint subclass is registered through Route(...) without an explicit methods= argument, the route does not constrain the method and every method reaches the endpoint. If a non-standard HTTP method whose lowercased name matches an attribute on the endpoint subclass reaches the endpoint, that attribute is invoked as if it were a request handler. An attacker can use this to reach methods that were never meant to be HTTP handlers, such as internal helpers, without the authorization checks applied by the intended public handler. Details HTTPEndpoint uses the client-supplied method name to resolve an instance attribute, without validating it against the set of HTTP verbs the endpoint supports. A method such as DODELETE therefore resolves an attribute like dodelete and…
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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, where uri-host follows the restricted host grammar of RFC 3986 §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…
Recommended action: Upgrade to 1.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated attacker can send a crafted HTTP Range header that triggers quadratic-time processing in Starlette's FileResponse Range parsing/merging logic. This enables CPU exhaustion per request, causing denial‑of‑service for endpoints serving files (e.g., StaticFiles or any use of FileResponse). Details Starlette parses multi-range requests in FileResponse.parserangeheader(), then merges ranges using an O(n^2) algorithm. The parsing loop of FileResponse.parserangeheader() uses the regular expression which vulnerable to denial of service for its O(n^2) complexity. A crafted Range header can maximize its complexity. The merge loop processes each input range by scanning the entire result list, yielding quadratic behavior with many disjoint ranges. A crafted Range header with many small, non-overlapping ranges (or specially shaped numeric substrings) maximizes comparisons. This affects any Starlette application that uses: - starlette.staticfiles.StaticFiles (internally…
Recommended action: Upgrade to 0.49.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When parsing a multi-part form with large files (greater than the default max spool size) starlette will block the main thread to roll the file over to disk. This blocks the event thread which means we can't accept new connections. Details Please see this discussion for details: https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403. In summary the following UploadFile code (copied from here) has a minor bug. Instead of just checking for self.inmemory we should also check if the additional bytes will cause a rollover. I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962 PoC See the discussion here for steps on how to reproduce. Impact To be honest, very low and not many users will be impacted. Parsing large forms is already CPU intensive so the additional IO block doesn't slow down starlette that much on systems with modern HDDs/SSDs. If someone is running on tape they might see a greater impact.
Recommended action: Upgrade to 0.47.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Starlette treats multipart/form-data parts without a filename as text form fields and buffers those in byte strings with no size limit. This allows an attacker to upload arbitrary large form fields and cause Starlette to both slow down significantly due to excessive memory allocations and copy operations, and also consume more and more memory until the server starts swapping and grinds to a halt, or the OS terminates the server process with an OOM error. Uploading multiple such requests in parallel may be enough to render a service practically unusable, even if reasonable request size limits are enforced by a reverse proxy in front of Starlette. PoC Impact This Denial of service (DoS) vulnerability affects all applications built with Starlette (or FastAPI) accepting form requests.
Recommended action: Upgrade to 0.40.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using StaticFiles, if there's a file or directory that starts with the same name as the StaticFiles directory, that file or directory is also exposed via StaticFiles which is a path traversal vulnerability. Details The root cause of this issue is the usage of os.path.commonprefix(): https://github.com/encode/starlette/blob/4bab981d9e870f6cee1bd4cd59b87ddaf355b2dc/starlette/staticfiles.py#L172-L174 As stated in the Python documentation (https://docs.python.org/3/library/os.path.html#os.path.commonprefix) this function returns the longest prefix common to paths. When passing a path like /static/../static1.txt, os.path.commonprefix([fullpath, directory]) returns ./static which is the common part of ./static1.txt and ./static, It refers to /static/../static1.txt because it is considered in the staticfiles directory. As a result, it becomes possible to view files that should not be open to the public. The solution is to use os.path.commonpath as the Python documentation…
Recommended action: Upgrade to 0.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The MultipartParser using the package python-multipart accepts an unlimited number of multipart parts (form fields or files). Processing too many parts results in high CPU usage and high memory usage, eventually leading to an <abbr title="out of memory"OOM</abbr process kill. This can be triggered by sending too many small form fields with no content, or too many empty files. For this to take effect application code has to: Have python-multipart installed and call request.form() or via another framework like FastAPI, using form field parameters or UploadFile parameters, which in turn calls request.form(). Patches The vulnerability is solved in Starlette 0.25.0 by making the maximum fields and files customizable and with a sensible default (1000). Applications will be secure by just upgrading their Starlette version to 0.25.0 (or FastAPI to 0.92.0). If application code needs to customize the new max field and file number, there are new request.form() parameters (with the…
Recommended action: Upgrade to 0.25.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.