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.)
I don't believe Python's urllib has a function that takes what HTTP terms an "origin-form" (an absolute path with possibly a query attached to it with "?") and parses it apart. Still, the RFC 9112 that defines HTTP/1.1 basics requires that, for the purposes of URI reconstruction, "if there is no Host header field or if its field value is empty or invalid, the target URI's authority component is empty."
BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass
41–50 of 65 posts
Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass
#42Earlier quoted context omitted.
Notably, Starlette powers FastAPI, an extremely popular Python framework for building HTTP services.
Is this still true?
You may be thinking of Litestar (previously named Starlite) that was based on Starlette akin to FastAPI but then went their own direction implementing a framework rather than relying on an upstream for their core product.
Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass
#43Never, 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.)
I don't believe Python's urllib has a function that takes what HTTP terms an "origin-form" (an absolute path with possibly a query attached to it with "?") and parses it apart. Still, the RFC 9112 that defines HTTP/1.1 basics requires that, for the purposes of URI reconstruction, "if there is no Host header field or if its field value is empty or invalid, the target URI's authority component is empty."
[dead]
Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass
#44[flagged]
Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass
#45Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass
#46Earlier quoted context omitted.
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
So an LLM was unable to reason about a codebase to find cross-library vulnerabilities. Your response was a weak excuse, it’s a clear demonstration of the shortcomings of LLMs which will inevitably cause headlines in the future.
If you point an LLM at a middleware and ask it to find vulnerabilities, then not finding this is a shortcoming.
Whether "LLM failed to spot vulnerability that took humans 8 years to find" is a great headline about shortcomings of LLMs is questionable, but it is a good example of a category of bug that is particularly hard to spot for humans and LLMs alike
Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass
#47Never, 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.)
Differentials between different URI parsers are a huge source of bugs. The amount of shenanigans you can do inside URIs is bonkers, and trying to handle this by yourself with some regex and string splitting is absolutely insane.
Like https://www.example.com:443@203569230:8080/ will send you to the IP address "12.34.56.78" on port 8080 using basic authentication with the domain and port as username and password. If your code tries to split by `:` or check that the URI starts with some specific string, then it won't be good enough. Indeed, use a library that you trust.
Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass
#48Never, 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.)
I don't believe Python's urllib has a function that takes what HTTP terms an "origin-form" (an absolute path with possibly a query attached to it with "?") and parses it apart. Still, the RFC 9112 that defines HTTP/1.1 basics requires that, for the purposes of URI reconstruction, "if there is no Host header field or if its field value is empty or invalid, the target URI's authority component is empty."
[deleted]
Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass
#49Earlier quoted context omitted.
I don't believe Python's urllib has a function that takes what HTTP terms an "origin-form" (an absolute path with possibly a query attached to it with "?") and parses it apart. Still, the RFC 9112 that defines HTTP/1.1 basics requires that, for the purposes of URI reconstruction, "if there is no Host header field or if its field value is empty or invalid, the target URI's authority component is empty."
https://docs.python.org/3/library/urllib.parse.html
Yep, none of them are suitable for this use case; you need to validate the Host header first and reconstruct the URI first before parsing it.
Re: BadHost – CVE-2026-48710: Starlette Host-Header Auth Bypass
#50Earlier quoted context omitted.
So an LLM was unable to reason about a codebase to find cross-library vulnerabilities. Your response was a weak excuse, it’s a clear demonstration of the shortcomings of LLMs which will inevitably cause headlines in the future.
If you point an LLM at a middleware and ask it to find vulnerabilities, then not finding this is a shortcoming. Whether "LLM failed to spot vulnerability that took humans 8 years to find" is a great headline about shortcomings of LLMs is questionable, but it is a good example of a category of bug that is particularly hard to spot for humans and LLMs alike
When the past month has been full of headlines claiming that Mythos et al. will be the end of secure software as well know it, it's fair game to emphasize the places we know already are not going to be covered by them.