CVE-2026-54283: Starlette ASGI Framework DoS Vulnerability

CVE-2026-54283 Overview

CVE-2026-54283 is a resource exhaustion vulnerability in Starlette, a lightweight Asynchronous Server Gateway Interface (ASGI) framework and toolkit used by many Python web applications and frameworks such as FastAPI. The flaw affects versions from 0.4.1 up to but not including 1.3.1. The request.form() method exposes max_fields and max_part_size parameters intended to bound resource consumption during form parsing. Starlette enforces these limits for multipart/form-data requests but silently ignores them for application/x-www-form-urlencoded bodies. An unauthenticated attacker can submit an oversized urlencoded body and bypass the application's configured safeguards.

Critical Impact
Unauthenticated attackers can send unbounded application/x-www-form-urlencoded requests to exhaust server memory and CPU, producing a denial-of-service condition against any Starlette-based service.

Affected Products

Starlette ASGI framework versions 0.4.1 through 1.3.0
Downstream frameworks built on Starlette (including FastAPI deployments) using affected versions
Python web services calling request.form() while relying on max_fields or max_part_size for input bounding

Discovery Timeline

2026-06-22 - CVE-2026-54283 published to the National Vulnerability Database
2026-06-23 - Last updated in NVD database

Technical Details for CVE-2026-54283

Vulnerability Analysis

The vulnerability is categorized as Allocation of Resources Without Limits or Throttling [CWE-770]. Starlette's request.form() method accepts two parameters, max_fields and max_part_size, that constrain how much data the parser will accept before raising an error. These constraints function correctly for the multipart parser path but are not propagated to the urlencoded parser path. As a result, an application that explicitly configures these limits has no protection when the client sets the Content-Type header to application/x-www-form-urlencoded.

Because the parser reads and decodes the entire request body into Python data structures, an attacker controls memory growth on the server. A single request containing millions of key=value& pairs, or a single very large field, forces the framework to allocate proportional memory and CPU during URL decoding and dictionary construction. The flaw is reachable without authentication on any endpoint that invokes request.form().

Root Cause

The root cause is a missing enforcement check in the urlencoded body parser. Where the multipart parser consults the configured limits and aborts when thresholds are exceeded, the urlencoded code path proceeds without applying the same bounds. The user-supplied limits are silently discarded, leaving the application unaware that its declared protections are ineffective.

Attack Vector

The attack is remote and network-based, requiring no privileges or user interaction. An attacker issues an HTTP POST or PUT request with the Content-Type header set to application/x-www-form-urlencoded and a body containing an excessive number of fields or an oversized field. The target endpoint must invoke request.form() during request handling. Repeated requests amplify the impact and can saturate worker processes, producing a denial of service against the application.

No verified public exploit code is available. See the GitHub Security Advisory for technical details.

Detection Methods for CVE-2026-54283

Indicators of Compromise

HTTP requests with Content-Type: application/x-www-form-urlencoded carrying unusually large Content-Length values directed at Starlette or FastAPI endpoints
Spikes in Python worker memory consumption or process restarts correlated with form-handling routes
Increased 5xx error rates, worker timeouts, or out-of-memory kills on ASGI server processes (Uvicorn, Hypercorn, Daphne)

Detection Strategies

Inspect web server and reverse proxy logs for POST or PUT requests where body size greatly exceeds typical form payloads for the route
Profile request handlers that call request.form() and alert on parse durations or allocation counts that deviate from baseline
Deploy a Web Application Firewall rule to flag urlencoded bodies exceeding a reasonable size threshold or containing an excessive number of & separators

Monitoring Recommendations

Track per-process resident memory and CPU on ASGI workers and alert on sustained growth tied to form-parsing code paths
Aggregate request body size percentiles per endpoint and alert on outliers above the 99th percentile
Capture stack traces during worker termination events to confirm whether request.form() is the source of allocation pressure

How to Mitigate CVE-2026-54283

Immediate Actions Required

Upgrade Starlette to version 1.3.1 or later in all affected environments, including transitive dependencies pulled in by FastAPI and similar frameworks
Audit application code for calls to request.form() and confirm that effective body-size limits are applied at the framework, reverse proxy, or WAF layer
Restrict maximum request body size at the reverse proxy (for example client_max_body_size in NGINX) to a value appropriate for legitimate form submissions

Patch Information

The vulnerability is fixed in Starlette 1.3.1. The fix applies the max_fields and max_part_size parameters to the application/x-www-form-urlencoded parser path so that limits behave consistently across content types. Refer to the GitHub Security Advisory GHSA-82w8-qh3p-5jfq for upstream commit references and release notes.

Workarounds

Place a reverse proxy or WAF in front of the application and enforce a strict maximum body size for application/x-www-form-urlencoded requests
Replace direct request.form() usage with a wrapper that inspects Content-Length and the Content-Type header, rejecting urlencoded bodies above an explicit threshold before parsing
Reject or rewrite requests whose Content-Type is application/x-www-form-urlencoded on endpoints that only expect JSON or multipart input

bash

# Configuration example: NGINX request body size limit
http {
    client_max_body_size 1m;

    server {
        location /api/ {
            client_max_body_size 256k;
            proxy_pass http://asgi_upstream;
        }
    }
}