Update dependency starlette to v1 [SECURITY] by renovate[bot] · Pull Request #22 · redhat-ai-dev/developer-images

renovate · 2024-12-20T16:34:26Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
starlette (changelog)	`==0.37.2` → `==1.3.1`

Starlette Denial of service (DoS) via multipart/form-data

CVE-2024-47874 / GHSA-f96h-pmfr-66vw

More information

Details

Summary

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

from starlette.applications import Starlette
from starlette.routing import Route

async def poc(request):
    async with request.form():
        pass

app = Starlette(routes=[
    Route('/', poc, methods=["POST"]),
])

curl http://localhost:8000 -F 'big=</dev/urandom'

Impact

This Denial of service (DoS) vulnerability affects all applications built with Starlette (or FastAPI) accepting form requests.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Starlette Denial of service (DoS) via multipart/form-data

CVE-2024-47874 / GHSA-f96h-pmfr-66vw

More information

Details

Summary

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

from starlette.applications import Starlette
from starlette.routing import Route

async def poc(request):
    async with request.form():
        pass

app = Starlette(routes=[
    Route('/', poc, methods=["POST"]),
])

curl http://localhost:8000 -F 'big=</dev/urandom'

Impact

This Denial of service (DoS) vulnerability affects all applications built with Starlette (or FastAPI) accepting form requests.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Starlette has possible denial-of-service vector when parsing large files in multipart forms

CVE-2025-54121 / GHSA-2c2j-9gv5-cj73

More information

Details

Summary

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._in_memory we should also check if the additional bytes will cause a rollover.

    @&#8203;property
    def _in_memory(self) -> bool:
        # check for SpooledTemporaryFile._rolled
        rolled_to_disk = getattr(self.file, "_rolled", True)
        return not rolled_to_disk

    async def write(self, data: bytes) -> None:
        if self.size is not None:
            self.size += len(data)

        if self._in_memory:
            self.file.write(data)
        else:
            await run_in_threadpool(self.file.write, data)

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.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security checks

CVE-2026-48710 / GHSA-86qp-5c8j-p5mr / PYSEC-2026-161 / X41-2026-002

More information

Details

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:

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:

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.

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

BadHost: Missing Host header validation poisons request.url.path, bypassing path-based security checks

CVE-2026-48710 / GHSA-86qp-5c8j-p5mr / PYSEC-2026-161 / X41-2026-002

More information

Details

Starlette reconstructs the requested URL based on the HTTP Host request header and requested path, but does not perform any validation of the Host header value. This allows attackers to inject paths into the host part, prepending the actual path. However, routing in Starlette is based on the actual request path. This inconsistent interpretation of HTTP requests may lead to issues such as authentication bypass when the authentication depends on the reconstructed URL’s path.

Severity

Unknown

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

Starlette: SSRF and NTLM credential theft via UNC paths in StaticFiles on Windows

CVE-2026-48818 / GHSA-wqp7-x3pw-xc5r

More information

Details

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.lookup_path() 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 (follow_symlink=False), which uses os.path.realpath. The follow_symlink=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.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Starlette: Arbitrary HTTP method dispatched to `HTTPEndpoint` attributes via `getattr`

CVE-2026-48817 / GHSA-x746-7m8f-x49c

More information

Details

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 _DO_DELETE therefore resolves an attribute like _do_delete 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.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Starlette: Unvalidated request path concatenated into authority poisons request.url.hostname

CVE-2026-54282 / GHSA-jp82-jpqv-5vv3

More information

Details

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 /:

GET @&#8203;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:

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".

Severity

CVSS Score: 3.7 / 10 (Low)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Starlette: request.form() limits silently ignored for application/x-www-form-urlencoded enable DoS

CVE-2026-54283 / GHSA-82w8-qh3p-5jfq

More information

Details

Summary

request.form() accepts max_fields and max_part_size 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 max_files, max_fields, and max_part_size limits are forwarded to the parser, but for application/x-www-form-urlencoded the parser is constructed without them. It has no max_fields or max_part_size 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 max_fields and max_part_size 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 (max_fields=1000, max_part_size=1MB) and can be customized via request.form(max_fields=..., max_part_size=...).

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

Kludex/starlette (starlette)

Conversation

renovate Bot commented Dec 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Starlette Denial of service (DoS) via multipart/form-data

Details

Summary

PoC

Impact

Severity

References

Starlette Denial of service (DoS) via multipart/form-data

Details

Summary

PoC

Impact

Severity

References

Starlette has possible denial-of-service vector when parsing large files in multipart forms

Details

Summary

Details

PoC

Impact

Severity

References

Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security checks

Details

Summary

Details

Impact

Mitigation

Severity

References

BadHost: Missing Host header validation poisons request.url.path, bypassing path-based security checks

Details

Severity

References

Starlette: SSRF and NTLM credential theft via UNC paths in StaticFiles on Windows

Details

Summary

Details

Impact

Mitigation

Severity

References

Starlette: Arbitrary HTTP method dispatched to HTTPEndpoint attributes via getattr

Details

Summary

Details

Impact

Mitigation

Severity

References

Starlette: Unvalidated request path concatenated into authority poisons request.url.hostname

Details

Summary

Details

Impact

Mitigation

Severity

References

Starlette: request.form() limits silently ignored for application/x-www-form-urlencoded enable DoS

Details

Summary

Details

Impact

Mitigation

Severity

References

Release Notes

v1.3.1: Version 1.3.1

What's Changed

v1.3.0: Version 1.3.0

What's Changed

New Contributors

v1.2.1: Version 1.2.1

What's Changed

New Contributors

v1.2.0: Version 1.2.0

What's Changed

renovate Bot commented Dec 20, 2024 •

edited

Loading

Starlette: Arbitrary HTTP method dispatched to `HTTPEndpoint` attributes via `getattr`

`v1.3.1`: Version 1.3.1

`v1.3.0`: Version 1.3.0

`v1.2.1`: Version 1.2.1

`v1.2.0`: Version 1.2.0

`v1.1.0`: Version 1.1.0

`v1.0.1`: Version 1.0.1

`v1.0.0`: Version 1.0.0

`v0.52.1`: Version 0.52.1

`v0.52.0`: Version 0.52.0

`v0.51.0`: Version 0.51.0

`v0.50.0`: Version 0.50.0

`v0.49.3`: Version 0.49.3

`v0.49.2`: Version 0.49.2

`v0.49.1`: Version 0.49.1

`v0.49.0`: Version 0.49.0

`v0.48.0`: Version 0.48.0

`v0.47.3`: Version 0.47.3

`v0.47.2`

`v0.47.1`: Version 0.47.1

`v0.47.0`: Version 0.47.0

`v0.46.2`: Version 0.46.2

`v0.46.1`: Version 0.46.1

`v0.46.0`: Version 0.46.0

`v0.45.3`: Version 0.45.3

`v0.45.2`: Version 0.45.2

`v0.45.1`: Version 0.45.1

`v0.45.0`: Version 0.45.0

`v0.44.0`: Version 0.44.0