CISA flags Starlette request smuggling and LiteLLM auth flaw as actively exploited

Two Python ecosystem CVEs hit CISA's exploited catalog

On 2 September 2026, CISA added two 2026 vulnerabilities in the Python web stack to its Known Exploited Vulnerabilities catalog, with a federal remediation deadline of 16 September. According to a dev.to analysis of the advisory, the first, CVE-2026-48710, affects the Starlette web framework and is described as HTTP request or response smuggling leading to authentication bypass. The second, CVE-2026-59822, affects BerriAI's LiteLLM and is described as improper authentication. The dev.to piece builds on the CISA catalog entry and on iThome reporting from 3 September.

What request smuggling does to a proxy chain

Request smuggling takes advantage of two components disagreeing about where one HTTP request ends and the next begins. When a front-end proxy and a back-end application read the same bytes differently, an attacker can craft input that the proxy treats as one request and the application treats as two. Two outcomes recur: cache poisoning, in which a response generated for one user is handed to another, and authentication bypass, in which a request gets charged to a session that never made it.

The problem is acute in ASGI deployments because the boundaries between layers are thin. The terminating proxy, framework middleware, and application-level authentication can each interpret headers such as content-length and transfer-encoding on their own. Starlette occupies the middle of that chain, which means a parsing defect in the framework sits in the shared path of everything built on top of it.

What makes the LiteLLM flaw distinct

LiteLLM is an AI gateway. Applications send it requests, it holds the provider API keys, it enforces budgets and rate limits, and it forwards traffic onward to model providers. Weak authentication in a gateway that fronts credentialed upstream services is more than a data leak, because the attacker acts under the gateway's identity. As the dev.to analysis points out, that means they can burn provider quota against the organisation's billing account, reach models the organisation has restricted, and in some designs coax the gateway into forwarding requests to internal endpoints.

Reporting cited in the post puts the affected LiteLLM range below 1.84.0 and advises upgrading and inspecting ~/.ssh/authorized_keys, a hint that exploitation may end in persistence on the host itself rather than only in the gateway configuration.

What operators should do now

For Starlette deployments the advice is to move to a fixed release and to verify that any reverse proxy in front of the application normalises request framing instead of forwarding ambiguous input untouched. Applications should authenticate against the framework's parsed view of a request rather than headers read independently, since the two can disagree.

For LiteLLM, upgrading closes the known flaw, but the post argues the gateway deserves the same scrutiny as any internet-facing authentication service: limit which networks can reach it, rotate provider keys and anything stored in authorized_keys if exposure is suspected, and comb gateway logs for requests that succeeded without a corresponding authentication event.

The supply chain angle

A defect at the framework level changes who does the patching work. The broken component may be a small dependency no team actively tracks, while the applications that need rebuilding live across many separate repositories. The dev.to author's observation is that the organisations which met CISA's 16 September deadline were largely those able to enumerate their Python services quickly, and that inventory is the part of the work which carries over to the next framework advisory.

Why it matters

A parsing flaw in a framework travels far: one bug in Starlette becomes every ASGI deployment's bug, and each deployment has to apply the fix on its own. A gateway authentication flaw compounds the problem, because LiteLLM instances hold the keys that let an attacker act as the organisation in front of model providers, with billing and access consequences that persist beyond the initial break-in. One caveat applies: the dev.to author notes that public reporting covers affected version ranges and exploitation status but stops short of publishing a working payload or a step-by-step bypass, so the mechanics described here should be read as the class of flaw each CVE belongs to rather than a confirmed reproduction.