CVE-2024-47874

What it actually does

Starlette versions before 0.40.0 parse multipart/form-data parts that do not include a filename parameter as ordinary text form fields and buffer those field values into in-memory byte strings without an effective per-field size limit. A remote unauthenticated client can send one or more very large multipart form fields without filenames, causing excessive memory allocation and byte-copying during request parsing. This can sharply increase CPU time, consume available RAM, trigger swapping, and eventually cause the application worker or container to be killed by the operating system for out-of-memory conditions. The impact is availability-only: it does not directly provide code execution, data access, or data modification.

Why it matters to the business

Public or internal services built on vulnerable Starlette versions, including FastAPI applications that rely on vulnerable Starlette parsing behavior, can be made slow or unavailable by relatively simple HTTP upload traffic. This can disrupt APIs, user-facing applications, background integrations, and dependent business workflows even where reverse proxies enforce general request-size limits, because the vulnerable parsing behavior occurs inside the application layer. The vulnerability is not in CISA KEV, has no known ransomware association, and has low EPSS at the time of assessment, but it is easy to trigger over the network and should be prioritized for internet-facing form-handling endpoints and services with strict availability requirements.

How an attack unfolds

An attacker first identifies an endpoint in a Starlette- or FastAPI-based service that accepts multipart/form-data, such as a form submission, upload workflow, or API endpoint using form parsing. Instead of sending a normal file part with a filename, the attacker sends one or more very large multipart parts with Content-Disposition set as a form field name only and no filename parameter. Vulnerable Starlette treats the part as a text field and buffers the entire value in memory. As the body grows, the application repeatedly allocates and copies large byte strings, increasing CPU and memory pressure. Repeating the request or sending several requests concurrently can exhaust worker memory, force system swapping, trigger request timeouts, or cause the OS/container runtime to terminate the application process. The result is denial of service for legitimate users until traffic stops, workers are restarted, or the vulnerable version is upgraded.

How to fix it

Upgrade Starlette to version 0.40.0 or later. For source-based deployments of encode/starlette, ensure the code includes the fix commit 4ded4b7ac517bd301cee69f5c189b1cb48c069b6 or a later release containing it. FastAPI applications should upgrade their dependency set so that the resolved Starlette version is 0.40.0 or newer, while verifying FastAPI compatibility constraints. Rebuild and redeploy containers or application artifacts after dependency updates; updating a lockfile alone is not sufficient. As defense in depth, enforce request body limits and multipart/form-data limits at all layers that support them, including reverse proxy, ASGI server, application middleware, and endpoint-specific validation. Consider rejecting multipart requests on endpoints that do not require them, limiting concurrent requests per client/IP, applying rate limits to form endpoints, and using memory/cpu limits with controlled worker restarts to prevent a single process from destabilizing the host.

How to confirm the fix worked

Confirm the deployed runtime dependency version, not only the repository declaration. Check package metadata with commands such as `python -m pip show starlette`, `python -m pip freeze`, Poetry/Pipenv lockfiles, SBOMs, or container image scans and verify Starlette is 0.40.0 or later. For FastAPI applications, inspect the resolved transitive dependency version of Starlette. Validate that deployed containers or serverless artifacts were rebuilt after the upgrade. Exercise representative multipart/form-data endpoints with benign size-limited tests and confirm that oversized form fields are rejected or bounded without sustained memory growth. Review reverse proxy, ASGI server, and application settings to confirm request-size and concurrency controls are active. Monitor during testing for stable resident memory, absence of OOM kills, and expected HTTP error responses for oversized requests.

Typical attack path

1. Identify a Starlette or FastAPI application endpoint that accepts form submissions using multipart/form-data.
2. Send a crafted multipart/form-data POST request containing a large non-file form part with a Content-Disposition name parameter but no filename parameter.
3. Cause the vulnerable parser to treat the large part as a text field and buffer it in memory without a safe per-field size limit.
4. Increase payload size or run multiple requests in parallel to amplify memory allocation, copy operations, CPU load, and swap activity.
5. Trigger application worker slowdown, timeout, out-of-memory termination, container restart, or service unavailability.

How to detect it

Investigate historical web access logs, reverse proxy logs, WAF logs, ASGI server logs, application logs, container runtime events, host kernel logs, and monitoring telemetry around periods of high memory use, worker restarts, or service degradation. Look for unusually large or long-running POST requests using Content-Type multipart/form-data, especially to form or upload endpoints, where request bodies are large but do not correspond to normal file-upload behavior. If request-body sampling is available, inspect multipart Content-Disposition headers for parts containing a name parameter but no filename parameter combined with very large field content. Correlate suspicious requests with rising application RSS memory, swap activity, CPU spikes, HTTP 499/500/502/503/504 responses, Gunicorn/Uvicorn worker timeouts, container OOMKilled events, Linux oom-killer messages, or sudden application restarts. Because many production logs do not capture multipart bodies, exploitation may be inferred from timing correlation between large multipart POST traffic and memory exhaustion rather than a definitive payload artifact.

• Content-Type: multipart/form-data
• Content-Disposition: form-data; name=
• filename=
• starlette.formparsers
• MemoryError
• Out of memory
• oom-killer
• Killed process
• OOMKilled
• Worker timeout
• WORKER TIMEOUT
• uvicorn
• gunicorn
• HTTP/1.1" 503
• HTTP/1.1" 504
• multipart/form-data; boundary=

What your security team should do

• Inventory Starlette and FastAPI services, prioritizing internet-facing endpoints and APIs that accept multipart/form-data or form submissions.
• Upgrade Starlette to 0.40.0 or later across all affected applications; ensure FastAPI dependency resolution does not pin Starlette below the fixed version.
• Redeploy rebuilt application artifacts and verify the running version from the deployed environment or container image.
• Add or tighten request body size limits, form field limits, upload limits, rate limiting, and per-client concurrency controls for form-handling routes.
• Review recent availability incidents, OOM kills, worker restarts, and spikes in multipart/form-data POST traffic for possible exploitation attempts.
• Create monitoring alerts for abnormal memory growth, swap usage, container OOMKilled events, repeated worker timeouts, and high volumes of multipart/form-data requests to the same endpoint.
• If immediate upgrade is not possible, temporarily disable or restrict vulnerable form endpoints, require authentication where appropriate, and place stricter controls at the reverse proxy or WAF layer.