CVE-2026-48061: 
Python vulnerability analysis and mitigation

CVE-2026-48061 is a host validation bypass vulnerability in the Litestar Python web framework's AllowedHostsMiddleware component, allowing attackers to circumvent allowed-hosts restrictions via a client-controlled X-Forwarded-Host header. It affects all versions of the litestar pip package up to and including 2.21.1, with the fix introduced in version 2.22.0. The vulnerability was first published on May 20, 2026, and added to the GitHub Advisory Database on June 10, 2026. It carries a CVSS v3.1 base score of 5.9 (Moderate) (GitHub Advisory, Litestar Advisory).

The root cause is classified under CWE-348 (Use of Less Trusted Source) and CWE-807 (Reliance on Untrusted Inputs in a Security Decision). In AllowedHostsMiddleware.__call__, the host resolution logic at allowed_hosts.py#L68 uses headers.get("host", headers.get("x-forwarded-host", "")).split(":")[0], meaning that when the Host header is absent — as can occur with HTTP/1.0 clients, misconfigured proxies, or raw TCP connections — the middleware falls back to the client-supplied X-Forwarded-Host header without verifying it passed through a trusted reverse proxy. An attacker can omit the Host header entirely and set X-Forwarded-Host to any whitelisted domain, causing the middleware to pass the request as if it originated from a trusted host. A public proof-of-concept demonstrating the bypass via direct ASGI scope manipulation is included in the advisory (GitHub Advisory, Fix Commit).

Successful exploitation allows an unauthenticated remote attacker to bypass the AllowedHostsConfig restriction and have requests processed as if they originated from a trusted host, with a high integrity impact and no confidentiality or availability impact per the CVSS scoring. The most significant downstream risks include password reset poisoning (where the application uses the resolved host to generate reset links, redirecting victims to an attacker-controlled domain), cache poisoning (polluting cached responses keyed on the host value), and routing manipulation (influencing backend routing or selection decisions). Applications deployed without a reverse proxy that strips X-Forwarded-Host, or those accepting HTTP/1.0 connections, are most exposed (Litestar Advisory).

1. Reconnaissance: Identify applications built on the Litestar framework (pip package litestar ≤ 2.21.1) that use AllowedHostsConfig and are directly internet-accessible or reachable without a hardening reverse proxy.
2. Determine whitelisted hosts: Probe the application to identify which hostnames are in the allowed hosts list (e.g., by observing redirect behavior or error messages when sending requests with various Host header values).
3. Craft the bypass request: Construct an HTTP request that omits the Host header entirely and includes an X-Forwarded-Host header set to a known whitelisted domain (e.g., X-Forwarded-Host: trusted.example.com).
4. Send the request: Transmit the crafted request directly to the application server (e.g., via raw TCP, HTTP/1.0, or a tool like curl with --http1.0 and custom headers), bypassing the AllowedHostsMiddleware validation.
5. Achieve objective: With the middleware bypassed, the application processes the request as trusted. Depending on application logic, the attacker can trigger password reset link generation pointing to an attacker-controlled domain, poison cached responses, or manipulate routing decisions (GitHub Advisory, Litestar Advisory).

• Network: Inbound HTTP requests to the application server that lack a Host header but include an X-Forwarded-Host header set to a whitelisted domain; HTTP/1.0 requests from unexpected sources targeting application endpoints.
• Logs: Web server or application access logs showing requests with no Host header field alongside a populated X-Forwarded-Host value; unexpected 200 responses to requests that should have been blocked (HTTP 400) by AllowedHostsMiddleware.
• Application Behavior: Password reset emails or generated links pointing to unexpected or external domains; anomalous cache entries keyed on unexpected host values; unusual backend routing behavior correlated with requests missing the Host header.

Upgrade the litestar pip package to version 2.22.0 or later, which fixes the issue by removing the X-Forwarded-Host fallback in AllowedHostsMiddleware (the host resolution is changed to headers.get("host").split(":")[0] only) (Fix Commit). As a workaround for deployments that cannot immediately upgrade, configure a trusted reverse proxy (e.g., nginx, Caddy) to strip or overwrite the X-Forwarded-Host header before requests reach the application, and ensure the proxy enforces the Host header. Additionally, block HTTP/1.0 connections at the network perimeter if not required (Litestar Advisory).