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.
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.
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
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.
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.)
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.
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."
You kind of have to, it's not turtles all the way down, at some point the network is sending strings my man.
You just have not to make mistakes, there's no silver bullet or instant cop-out like "this would never happen to me because I don't do one of the things in this multi-sub-system vuln".
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.
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.
Or probably the most straightforward one, which is SSL termination. Most backend software usually has very bad support for HTTPS communication, while it's typically extensively documented for something like nginx. It also catches some other strangeness like making it easier to update the certificate.
The biggest risk is incorrect usage of the default_server directive, the proper way in which to handle it isn't usually taught in most "here's how you use nginx" tutorials. Most usually just have you edit the default server blocks.
Tldr that covers 99% of all cases: you want 2 default server blocks, one on port 80 and one on port 443. The one on port 80 should only return 444 (an internal nginx status code that stops the connection immediately with no response), while the one on port 443 should use ssl_reject_handshake to terminate the SSL connection as quickly as possible without causing strange errors (you also need a self-signed certificate because otherwise openssl refuses to do protocol negotiation correctly, but the cert doesn't actually do anything). After that, specify your actual domains as separate server blocks using server_name (including a separate one for each to do the port 80->443 redirect).
Arguably this should be the default configuration shipped by distros, but it isn't for some reason, which doesn't help matters.
If I’m reading https://github.com/nginx/nginx/pull/966 right (not a given on my phone), just having Nguni in front would help because It’s now filtering the characters which make this attack possible.
But you have to be super careful about defining the mitigations for this one, as for example Cloudflare passes malicious headers as-is without extra configuration, leaving hosts vulnerable when they are assumed to be protected.
Yes. you always want to test any mitigation but Cloudflare and AWS ALBs both blocked non-DNS characters in host headers with no additional configuration when I tested it. It would be surprising if Cloudflare didn’t because the Host header is how they know which customer to route a request to.
Ars has had a depreciating quality the past few years by most accounts. They've been trying a bit harder recently it seems, but shaking off the allure of half baked short form journalism is hard, I guess.
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.
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.
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.
Also requires that you build specific kind of logic in your access control. So it really depends on implementation. Some codebases are vulnerable where as others are not.
Is catchy name with domain and website for every vulnerability now the norm? I mean it's good that it was found but there have been a lot of vulnerability websites lately.
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
I need to start some kind of public counter for major vulnerabilities that could have been prevented with a software building code. It's been ticking up a lot latey
Notably CVE-2026-48710 hasn't been added into cloud sec vuln catalogs quite yet. Since fastapi ~is starlette, expect the later half of this week / early next to be busy.
I think there’s a solid argument for global auth middleware, where this is a problem if you use the path for exceptions like health-checks or a login endpoint.
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.
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.
https://github.com/fastapi/fastapi/blob/master/pyproject.tom...
..And?
FastAPI depends on "starlette>=0.46.0"
And? It's a non-sequitur to my comment.
Yes, it's literally the first bullet point on the project's website.
[dead]
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
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.
The posted page said that finding logic bugs of this kind requires ‘understanding’ which LLM cannot.
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.)
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.
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.
[dead]
You kind of have to, it's not turtles all the way down, at some point the network is sending strings my man.
You just have not to make mistakes, there's no silver bullet or instant cop-out like "this would never happen to me because I don't do one of the things in this multi-sub-system vuln".
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.
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.
Or probably the most straightforward one, which is SSL termination. Most backend software usually has very bad support for HTTPS communication, while it's typically extensively documented for something like nginx. It also catches some other strangeness like making it easier to update the certificate.
The biggest risk is incorrect usage of the default_server directive, the proper way in which to handle it isn't usually taught in most "here's how you use nginx" tutorials. Most usually just have you edit the default server blocks.
Tldr that covers 99% of all cases: you want 2 default server blocks, one on port 80 and one on port 443. The one on port 80 should only return 444 (an internal nginx status code that stops the connection immediately with no response), while the one on port 443 should use ssl_reject_handshake to terminate the SSL connection as quickly as possible without causing strange errors (you also need a self-signed certificate because otherwise openssl refuses to do protocol negotiation correctly, but the cert doesn't actually do anything). After that, specify your actual domains as separate server blocks using server_name (including a separate one for each to do the port 80->443 redirect).
Arguably this should be the default configuration shipped by distros, but it isn't for some reason, which doesn't help matters.
If I’m reading https://github.com/nginx/nginx/pull/966 right (not a given on my phone), just having Nguni in front would help because It’s now filtering the characters which make this attack possible.
But you have to be super careful about defining the mitigations for this one, as for example Cloudflare passes malicious headers as-is without extra configuration, leaving hosts vulnerable when they are assumed to be protected.
Yes. you always want to test any mitigation but Cloudflare and AWS ALBs both blocked non-DNS characters in host headers with no additional configuration when I tested it. It would be surprising if Cloudflare didn’t because the Host header is how they know which customer to route a request to.
Ars has had a depreciating quality the past few years by most accounts. They've been trying a bit harder recently it seems, but shaking off the allure of half baked short form journalism is hard, I guess.
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!
So the classic case of two parsers disagreing and being too permissive in accepting input
[dead]
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.
Also requires that you build specific kind of logic in your access control. So it really depends on implementation. Some codebases are vulnerable where as others are not.
I don't know if many people run FastAPI directly without any reverse proxy, load balancer etc. in front of their services.
Probably this is why it is marked as medium.
Is catchy name with domain and website for every vulnerability now the norm? I mean it's good that it was found but there have been a lot of vulnerability websites lately.
they should make a .cve tld to make keeping track of these easier.
https://www.cve.org/
It's a bit of an overkill but then again, why not.
Setting aside this issue, Starlette is a really great web server.
If you do async python I strongly recommend it.
FastAPI is built on Starlette - to be honest I don’t see the point of the extra baggage - just use Starlette.
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?
the lore: https://en.wikipedia.org/wiki/Flask_(web_framework)#History
Yes sir, more flaskatronic.
I need to start some kind of public counter for major vulnerabilities that could have been prevented with a software building code. It's been ticking up a lot latey
Notably CVE-2026-48710 hasn't been added into cloud sec vuln catalogs quite yet. Since fastapi ~is starlette, expect the later half of this week / early next to be busy.
path-based auth middleware is a bad practice IMHO
I think there’s a solid argument for global auth middleware, where this is a problem if you use the path for exceptions like health-checks or a login endpoint.
[flagged]
The URL was meant to be https://badhost.org, the site accidentally still has the old canonical meta tag.
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]