--- title: "Security Advisory: CVE-2026-48710 (\"BadHost\")" description: "Published: May 28, 2026" --- # Security Advisory: CVE-2026-48710 ("BadHost") **Published:** May 28, 2026 **Severity:** Remote authentication bypass (Starlette / FastAPI) ### TL;DR Host-header bypass in Starlette library < 1.0.1 (incl. FastAPI). Anyscale's own Service auth isn't affected, so it's only a problem if _your_ app uses middleware to gate routes like `/admin` — urgent if so, hygiene if not. Fix: pin `starlette>=1.0.1`, rebuild, redeploy. ## What it is A Host-header authentication bypass in the Starlette ASGI framework, and anything built on top of it (notably FastAPI). All Starlette versions **prior to 1.0.1** are affected. A remote, unauthenticated attacker can inject characters such as `/`, `?`, or `#` into the HTTP `Host` header, causing Starlette to reconstruct `request.url.path` with a path boundary in the wrong place. Path-based auth middleware sees a different path than the one the ASGI server actually routes against, and the auth check is skipped. The patch shipped on May 21, 2026 — one day before public disclosure — so vulnerable versions remain widely deployed. A public proof-of-concept exists. The vulnerability affects any Python ASGI app that relies on path-based auth middleware in Starlette or FastAPI, including MCP servers, LLM proxies (vLLM, LiteLLM), AI agent frameworks, and many Ray Serve applications. ## Are you affected? You are affected if **both** of the following are true: 1. You run Anyscale Services that expose an HTTP endpoint reachable from the public internet, **and** 2. Your Anyscale cloud was provisioned in one of the following ways: - With `anyscale cloud setup` (the managed setup path always provisions a public-networking cloud), **or** - With `anyscale cloud register` **without** the `--private-network` flag. If your cloud was registered with `anyscale cloud register --private-network`, your Services endpoints are not reachable from the public internet and BadHost cannot be exploited remotely. You are not affected by the public-internet attack path, though Anyscale still recommends the upgrade as defense-in-depth. To check which method was used, see [Configure AWS resources for an Anyscale cloud → Methods](https://docs.anyscale.com/clouds/aws/configure#methods). ## Real-world risk for Anyscale Services Anyscale's own authentication on the Services endpoint — the bearer-token check that fronts every Service — runs before your application code and is **not** affected by BadHost. The vulnerability only bypasses authentication that _your_ Starlette or FastAPI middleware performs inside the application. **For typical Ray Serve applications with no in-app auth middleware, the marginal risk that BadHost adds above this existing baseline is low.** The upgrade is still recommended because Starlette is pulled in transitively by Ray, vLLM, LiteLLM, and most MCP server implementations, and any future middleware you add would inherit the bypass. **For Services that use Starlette/FastAPI middleware to gate specific routes** (for example an `/admin` path, an internal `/metrics` endpoint, or a tool-router in an MCP server), an attacker on the internet can reach the gated handler unauthenticated. Treat as urgent. ## Mitigation Upgrade Starlette to **1.0.1 or later** in your Service's container image. Starlette 1.0.1 was released on May 21, 2026 and is the upstream fix. ```python starlette>=1.0.1 ``` The fix lives in Starlette itself. FastAPI pulls Starlette in as a dependency, so for FastAPI users: - If your pinned FastAPI version already allows `starlette>=1.0.1`, you only need to add or bump the Starlette pin and rebuild. - If your pinned FastAPI version caps Starlette below 1.0.1, also upgrade FastAPI to a release whose dependency range admits Starlette 1.0.1. Rebuild the image and redeploy: ```bash anyscale service deploy ... ``` Services performs a rolling update; there is no downtime. Verify the running version on a deployed replica: ```bash anyscale service exec --name -- python -c "import starlette, fastapi; print(starlette.__version__, fastapi.__version__)" ``` ## Apply across all your Services List every Service in your cloud and check its image: ```bash anyscale service list --output json | jq -r '.[] | [.name, .container_image] | @tsv' ``` For each Service whose image pins a vulnerable Starlette or FastAPI version, rebuild the image with the patched versions above and redeploy. **Important:** Services autoscale. New replicas pull the image that was current at deploy time. Until you redeploy with a patched image, any newly-launched replica will still be vulnerable. ## Private-networking deployments If your cloud was registered with `anyscale cloud register --private-network`, your Service endpoints are reachable only from inside your VPC. BadHost cannot be exploited from the public internet, so urgency is lower. Anyscale still recommends upgrading as defense-in-depth — an attacker who already has a foothold inside your VPC, or any internal service that calls your endpoint, can still trigger the bypass. ## Kubernetes deployments Anyscale does not distribute the container images you run on your own Kubernetes cluster. The mitigation is the same: pin patched Starlette and FastAPI in your image and roll your Service pods. ## Anyscale Ray base images The Anyscale Ray base images ([docs](https://docs.anyscale.com/reference/base-images)) will be refreshed to pin `starlette>=1.0.1` as part of the next base image release. Customers who rebuild their Service image against the refreshed Anyscale base image will pick up the fix automatically without any changes to their own `requirements.txt`. If you build your Service image on top of an Anyscale Ray base image and don't pin Starlette explicitly, rebuilding against the refreshed base image is sufficient. If you do pin Starlette explicitly, you also need to bump your pin to `>=1.0.1`. ## Anyscale platform mitigation **Target: TBD.** Anyscale will ship an AMI update that hardens the platform's ingress against the BadHost attack pattern. Once rolled out, customers on Anyscale-managed clouds will have an additional layer of protection at the ingress, independent of the Starlette version inside their Service. This platform-level mitigation is defense-in-depth, **not** a replacement for upgrading Starlette in your Service image. The customer-side fix above remains the complete and authoritative remediation, and customers should apply it without waiting for the AMI rollout. If you require the updated AMI sooner for compliance or contractual reasons, contact Anyscale support. ## References - Disclosure: [https://badhost.org/](https://badhost.org/) - Anyscale Ray base images: [https://docs.anyscale.com/reference/base-images](https://docs.anyscale.com/reference/base-images) - Anyscale public/private networking: [https://docs.anyscale.com/clouds/aws/configure#methods](https://docs.anyscale.com/clouds/aws/configure#methods) --- Previous: [Compare Anyscale base images](/reference/base-images/compare.md) | Next: [CVE-2026-31431 (CopyFail)](/security/bulletins/260430-copyfail.md)