Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass

badhost.org

Post reply on HN
Print view View original

1–10 of 65 posts

Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass

#3

Post by ostif-derek »

This is a bad one. Rating it a medium understates how hard it hits thousands of downstream projects and billions of installs. People need to patch asap. I'm normally against the "giving a bug a name, logo, and website" trope, but this one is getting poor patch rates because of it being rated a medium and landing right before a big American holiday weekend.

Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass

#4

Post by acdha »

ostif-derek wrote: post #3

This is a bad one. Rating it a medium understates how hard it hits thousands of downstream projects and billions of installs. People need to patch asap. I'm normally against the "giving a bug a name, logo, and website" trope, but this one is getting poor patch rates because of it being rated a medium and landing right before a big American holiday weekend.

I agree it’s fairly bad on its own but it’s substantially mitigated if you aren’t exposing Starlette/FastAPI directly to the internet – if you use a CDN, load-balancer / API Gateway, or a fronting web server it’s likely that your service is protected since the attacks depend on characters which are not valid in DNS (and in the first couple of cases, likely need to match to route traffic to the right customer).

As an example, I just confirmed that both Cloudflare and AWS ALBs reject all of the attack patterns. Still not good, lateral movement is a time-honored tactic, etc. but it buys time to patch.

Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass

#6

Post by s2l »

From the link, on how the attack works:

An attacker can send a crafted request like GET /protected with a Host: example.com/health?x= header. The request will reach the /proteced path, but request.url would be https://example.com/health?x=/protected, and request.url.path would return /health instead of the real request path.

Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass

#7

Post by nickcw »

If you read the advisory and are wondering what starlette is, from it's web page: starlette is a lightweight ASGI framework/toolkit, which is ideal for building async web services in Python.

It's used a lot in the data heavy AI world for it's efficiency shipping large files. This includes lots and lots of production servers.

From the advisory: this includes LLM inference servers like vLLM, LLM proxy servers like LiteLLM, AI agent frameworks, MCP gateways, and custom APIs. MCP servers are especially at risk because the MCP spec mandates unauthenticated OAuth discovery endpoints, providing a reliable path for exploitation.

Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass

#8

Post by alex_suzuki »

nickcw wrote: post #7

If you read the advisory and are wondering what starlette is, from it's web page: starlette is a lightweight ASGI framework/toolkit, which is ideal for building async web services in Python. It's used a lot in the data heavy AI world for it's efficiency shipping large files. This includes lots and lots of production servers. From the advisory: this includes LLM inference servers like vLLM, LLM proxy servers like Lite…

Notably, Starlette powers FastAPI, an extremely popular Python framework for building HTTP services.

Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass

#10

Post by noirscape »

If you're using nginx/apache/literally anything that does reverse proxying correctly, this shouldn't be a problem unless you're routing all traffic over default_server rules unstead of server_name (or the equivalent).

They should be stopping this attack at the door (even if only to clean out your logs from scraper door knocks), which is probably why it went unnoticed for years. I don't think anyone would be deploying {A,W}SGI servers on public facing ports these days. Even if only because SSL termination is much easier in the proxy layer.

Also good lord that ARS article is a mess. What the hell happened there? An ASGI server isn't unique to AI or anything, it's just a regular supply chain dependency. I kinda expect better from ARS on stuff like this.

Post reply on HN