DEV Community

jeffrey
jeffrey

Posted on

Request Smuggling in the ASGI Stack: Starlette and LiteLLM

Request Smuggling in the ASGI Stack: Starlette and LiteLLM

Why framework-level parsing flaws travel far

A web framework that parses requests incorrectly affects every application built on it, and the fix has to be applied in each of those deployments. Two 2026 CVEs make the point in the Python ecosystem. CVE-2026-48710 in the Kludex Starlette framework is described as HTTP request or response smuggling leading to authentication bypass, and CVE-2026-59822 in BerriAI LiteLLM is described as improper authentication. Both were added to CISA's Known Exploited Vulnerabilities catalog on 2 September 2026, with a federal remediation deadline of 16 September.

What request smuggling does to a front proxy

Request smuggling exploits a disagreement about where one request ends and the next begins. If a front-end proxy and a back-end application parse the same bytes differently, an attacker can construct input that the proxy reads as one request and the application reads as two. The classic results are cache poisoning, where a response intended for one user is served to another, and authentication bypass, where a request is attributed to a session that did not originate it.
In an ASGI deployment the layer boundary is particularly thin. Terminating proxies, framework middleware, and application-level authentication may each make their own decisions about headers such as content length and transfer encoding. Starlette sits in the middle of that chain, so a parsing defect there is a defect in the shared path of everything built on it.

Why LiteLLM is adjacent to the same problem

LiteLLM is an AI gateway. It accepts requests from applications, holds provider API keys, enforces budgets and rate limits, and forwards to model providers. Improper authentication in a gateway that sits in front of credentialed upstream services is not only a data exposure, because the attacker operates with the gateway's identity. They can consume provider quota under the organisation's billing account, reach models the organisation restricts, and in some designs cause the gateway to forward requests to internal endpoints.
Public reporting on the LiteLLM flaw identifies affected versions below 1.84.0 and recommends upgrading and checking ~/.ssh/authorized_keys, which suggests the exploitation path can end in persistence on the host rather than in the gateway configuration alone.

Remediation notes for both

For Starlette, the practical steps are upgrading to a fixed release and confirming that a reverse proxy in front of the application normalises request framing rather than passing ambiguous input through. Applications should authenticate on the framework's parsed view of the request rather than on headers read independently, because the two can disagree.
For LiteLLM, upgrading addresses the known flaw. Before and after, the gateway deserves the same scrutiny as an internet-facing authentication service: restrict which networks can reach the proxy, rotate provider keys and any credentials stored in ~/.ssh/authorized_keys if exposure is suspected, and review gateway logs for requests that returned success without a matching authentication event.

The supply chain dimension

A framework flaw inverts the usual patching incentives. The component with the defect may be a small dependency that nobody tracks, while the applications that must be rebuilt sit in dozens of repositories. CISA's deadline for both CVEs was 16 September, and the organisations that met it were, in practice, those that could enumerate their Python services quickly. Building that inventory is the part of the work that carries over to the next framework advisory.
Public reporting for Starlette and LiteLLM identifies the affected version ranges and the exploitation status but does not publish a full payload or a step-by-step bypass, so the mechanism here should be read as the class of flaw each CVE belongs to rather than a confirmed reproduction.

References

Top comments (0)