CVE-2026-48710 is a vulnerability in the Starlette ASGI framework where a specially crafted HTTP Host header can cause the reconstructed request URL to differ from the actual requested path. This discrepancy can lead to security restrictions being bypassed if applications rely on the reconstructed URL for access control instead of the canonical ASGI path. The impact depends on application design and is rated moderate by Red Hat, with many affected Red Hat products rated as low impact due to deployment architectures and authentication methods. Mitigations include deploying an RFC-compliant reverse proxy to reject malformed Host headers and updating middleware to use the ASGI scope path for security decisions.

Red Hat Security Advisory: satellite/iop-vulnerability-engine-rhel9 container image available as a Technology Preview

snyk-agent-scan

Starlette versions from 0.4.3 up to but not including 0.5.4_1 have a vulnerability where the HTTP Host header is not validated before reconstructing request.url. This allows an attacker to craft a malformed Host header that causes request.url.path to differ from the actual requested path, potentially bypassing path-based security checks that rely on request.url.path. The issue is fixed in version 0.5.4_1 by validating the Host header against RFC 9112 and RFC 3986 grammar and falling back to a safe value if malformed.

Snyk agent scan: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based…

semgrep

Starlette versions from 1.137.0 up to but not including 1.165.0 improperly validate the HTTP Host header when reconstructing request.url, allowing a malformed Host header to cause request.url.path to differ from the actual requested path. This discrepancy can lead to bypass of path-based security checks if middleware or endpoints rely on request.url.path rather than the canonical ASGI path. The vulnerability does not directly grant access or modify routing but can enable bypass only if applications depend on the flawed request.url.path for authorization. The issue is mitigated by validating the Host header per RFC 9112 and falling back to server scope for malformed values. A fix is available in version 1.165.0.

Semgrep: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security…

oterm

A vulnerability in Starlette versions >=0.13.1 and <0.17.2_1 allows an attacker to send a malformed HTTP Host header that causes the reconstructed request.url.path to differ from the actual requested path. This discrepancy can bypass security checks that rely on request.url.path for path-based authorization. The issue is fixed in version 0.17.2_1. The impact depends on application design, specifically if security decisions are based on request.url.path rather than the canonical ASGI path. Reverse proxies that validate Host headers can mitigate this risk.

Oterm: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security…

mcpm

A vulnerability in Starlette versions >=1.0.3 and <2.15.0 allows an attacker to bypass path-based security checks by sending a malformed HTTP Host header. This causes the reconstructed request.url.path to differ from the actual requested path, potentially bypassing middleware or endpoint security that relies on request.url.path. The vulnerability is mitigated by validating the Host header against RFC 9112 and RFC 3986 grammar or by using a reverse proxy that rejects malformed Host headers.

Mcpm: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security checks…

mcp-atlassian

A vulnerability in Starlette allows an attacker to send a malformed HTTP Host header that causes the reconstructed request.url.path to differ from the actual requested path. This discrepancy can bypass security checks in middleware or endpoints that rely on request.url.path for access control. The issue affects versions from 0.11.9 up to but not including 0.21.1_7. The vulnerability does not directly grant unauthorized access but can lead to path-based authorization bypass if the application depends on request.url.path instead of the canonical ASGI path. Mitigation involves upgrading to a fixed version or using an RFC-compliant reverse proxy to reject malformed Host headers.

Mcp atlassian: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based…

mcp-google-sheets

### Summary
In affected versions, the HTTP `Host` request header was not validated before being used to reconstruct `request.url`. Because the routing algorithm relies on the raw HTTP path while `request.url` is rebuilt from the `Host` header, a malformed header could make `request.url.path` differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on `request.url` (rather than the raw `scope` path) could therefore be bypassed.

### Details
When a client requests `http://example.com/foo`, it sends:

```http
GET /foo HTTP/1.1
Host: example.com
```

Affected versions reconstructed the URL by concatenating `http://{host}{path}` and re-parsing the result. The `Host` value is only valid as a `uri-host [ ":" port ]` per [RFC 9112 §3.2](https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2-6), where `uri-host` follows the restricted `host` grammar of [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2). When it contains characters outside that grammar - notably `/`, `?`, or `#` - those characters move the path/query/fragment boundaries during re-parsing, so the parsed `request.url.path` no longer matches the path the server actually received. For example:

```http
GET /foo HTTP/1.1
Host: example.com/abc?bar=
```

reconstructs to `http://example.com/abc?bar=/foo`, whose parsed `path` is `/abc` - even though routing used the real path `/foo`. The router still dispatches to `/foo` and the endpoint executes, but any middleware or code that reads `request.url.path` sees `/abc`, so path-based authorization checks can be bypassed.

### Impact
Any application running an affected version that relies on `request.url` (or `request.url.path`) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on `request.url.path`. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed `Host` header before forwarding and the application does not trust attacker-controlled host headers (e.g. `X-Forwarded-Host`) elsewhere.

### Mitigation
Upgrade to a patched version, which validates the `Host` header against the grammar of [RFC 9112 §3.2](https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2-6) / [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2) when constructing `request.url` and falls back to `scope["server"]` for malformed values.

Mcp google sheets: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based…

glances

A vulnerability in Starlette, a lightweight ASGI framework, allows an attacker to send a malformed HTTP Host header that causes the reconstructed request.url.path to differ from the actual requested path. This discrepancy can lead to bypassing path-based security checks if the application relies on request.url.path for authorization decisions. The flaw affects versions from 4.2.1 up to but not including 4.5.4_3. A fix is available in version 4.5.4_3. The impact depends on application design and is rated medium severity with a CVSS score of 6.5. Mitigation includes upgrading to a patched version or deploying a reverse proxy that validates Host headers according to RFC standards.

Glances: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security…

fastmcp

A vulnerability in Fastmcp's Starlette framework allows an attacker to bypass path-based security checks by sending a malformed HTTP Host header. The Host header is not properly validated before reconstructing request.url, causing request.url.path to differ from the actual requested path. Applications relying on request.url.path for security decisions may be bypassed. The issue is fixed in version 3.3.1_1. Mitigation includes upgrading to the fixed version or deploying a reverse proxy that rejects malformed Host headers.

Fastmcp: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security…

esphome

A vulnerability in Starlette used by Esphome allows an attacker to bypass path-based security checks by sending a malformed HTTP Host header. This causes the reconstructed request.url.path to differ from the actual requested path, potentially bypassing middleware or endpoint security that relies on request.url.path. The issue affects versions of Esphome using Starlette between 2022.1.2 and before 2023.10.0, and between 2024.2.1 and before 2026.10.0. A fix is available in versions 2023.10.0 and 2026.10.0. The vulnerability is rated medium severity with a CVSS score of 6.5. Mitigation includes upgrading to a patched version or deploying an RFC-compliant reverse proxy to reject malformed Host headers.

Esphome: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security…

dstack

A vulnerability in Starlette, used by dstack, allows an attacker to send a malformed HTTP Host header that causes the reconstructed request.url.path to differ from the actual requested path. This discrepancy can bypass security checks that rely on request.url.path for path-based authorization. The issue affects versions from 0.0.14 up to but not including 0.21.0. The vulnerability is mitigated by validating the Host header against RFC grammar and falling back to a safe value for malformed headers. Deployments behind reverse proxies that reject malformed Host headers are also protected. A fix is available in version 0.21.0.

Dstack: Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security…

kimi-cli

theharvester

gptme

starlette

Satellite provides a container image that you can use to run an MCP server locally. The MCP server for Satellite is designed for advanced reporting and data analysis that leverages AI capabilities. You can use it to generate dynamic and comprehensive reports from your Satellite inventory.

Red Hat Security Advisory: satellite/foreman-mcp-server-rhel9 container image available as a Technology Preview

Starlette is a lightweight ASGI framework/toolkit. Prior to version 1.0.1, the HTTP `Host` request header was not validated before being used to reconstruct `request.url`. Because the routing algorithm relies on the raw HTTP path while `request.url` is rebuilt from the `Host` header, a malformed header could make `request.url.path` differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on `request.url` (rather than the raw `scope` path) could therefore be bypassed. Users should upgrade to a version greater than or equal to version 1.0.1, which validates the `Host` header against the grammar of RFC 9112 §3.2 / RFC 3986 §3.2.2 when constructing `request.url` and falls back to `scope["server"]` for malformed values.

Search: CVE-2026-48710