Skip to main content

Security Advisory: CVE-2026-48710 ("BadHost")

View Markdown

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.

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.

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:

anyscale service deploy ...

Services performs a rolling update; there is no downtime.

Verify the running version on a deployed replica:

anyscale service exec --name <service-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:

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) 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​