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

21–30 of 65 posts

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

#21

Post by ostif-derek »

noirscape wrote: post #10

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…

You're relying on everyone in the world to set things up in a way that provides defense in depth. Not everyone is going to do that.

Which means there's going to be a lot of cases where people don't do the safe thing.

Especially, as other's have said, in the case of MCP servers, where the spec mandates exposed oauth.

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

#22

Post by nickcw »

s2l wrote: post #6

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.

I found a similar vulnerability in the Zeus Web Server ( https://en.wikipedia.org/wiki/Zeus_Web_Server ) in January 2000.

Zeus had a great feature where you could set up virtual servers just by creating directories. So if you wanted to host www.example.com and www.anotherexample.com you just created two directories of those names like that and away you went.

I discovered that the if you sent `Host:` headers which started with `/` then you could use it to traverse the file system and read any file you wanted.

Plus ça change, plus c'est la même chose!

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

#23

Post by andrewstuart »

Muromec wrote: post #20
0123456789ABCDE wrote: post #16

Earlier quoted context omitted.

fastAPI will give you `/openapi.json`, `/docs` with no extra effort function name becomes a human readable summary, string docs the description edit: bottle.py and fastapi are the most significant contributions to web frameworks in python — decorators for path handlers, typed input/output, automatic docs

Is it like flask, but even flaskier?

Yes sir, more flaskatronic.

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

#26

Post by magnio »

Never, ever, ever transform URIs and paths by string manipulation. If you think pulling in a library for this is overkill, it is not.

(Lesson learned from trying to quickly write my own function to make ".." to go back one URL segment that took 3 hours and discovering the URI spec contradicts my intuition depending on whether the URI is a URL or filesystem path.)

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

#27

Post by huflungdung »

s2l wrote: post #6

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.

[dead]

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

#28

Post by wongarsu »

hsbauauvhabzb wrote: post #14
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…

Ironically typing ‘make sure my server is secure’ into an LLM either wasn’t done, or missed it until now.

The posted page has an entire section titled "Why didn't Mythos find this?"

tl;dr: the bug spans three components in different code bases that when looked at in isolation each do reasonable things. The bug is in the interaction, in the assumed properties of the value that eventually gets exposed as request.url.path. That was apparently too subtle for current Anthropic models to spot

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

#29

Post by acdha »

ostif-derek wrote: post #21
noirscape wrote: post #10

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…

You're relying on everyone in the world to set things up in a way that provides defense in depth. Not everyone is going to do that. Which means there's going to be a lot of cases where people don't do the safe thing. Especially, as other's have said, in the case of MCP servers, where the spec mandates exposed oauth.

The saving grace here is that people are most commonly doing this for reasons other than as a defense - serving static files efficiently, combining multiple services, caching, DDoS protection, etc. There are certainly some directly exposed FastAPI instances but it’s been against the grain for decades.
Post reply on HN