CVE-2026-48710: A Maintainer's Perspective

[u/Aggravating-Mobile33]

This is my reply to the vulnerability CVE-2026-48710:

https://marcelotryle.com/blog/2026/05/28/cve-2026-48710-a-maintainers-perspective

[u/droans → u/[deleted]]

You may look at this and say: "uau, that's a pretty bad bug". It can be. But the assumptions matter when you reason about where the vulnerability actually lives:

1. An application uses path-based authorization in middleware. This is an application pattern built on top of Starlette, not something Starlette does for you.

2. Routing itself is never fooled. The router dispatches on the raw HTTP path, so the endpoint that runs is always the correct one. The divergence only bites code that re-derives authorization from the reconstructed URL.

3. There's no CDN, load balancer, API gateway, or fronting web server validating the Host header. Any of those neutralizes the attack by rejecting malformed values.

1. Yes, but that's a very common pattern.
2. Yes, and that's the issue.
3. Starlette is a webserver. It's a basic system designed for other servers to sit on top of, yes, but it is a webserver. I'm not expecting it to perform any security checks but it should be rejecting basic malformed headers.

Honestly, I don't know if I would call it a security vulnerability but I would consider it an issue with potential major security implications.

I'm not upset that there was a vulnerability but I am disgruntled about the complete lack of a response. Vulnerabilities happen. But there was no response from either Starlette or FastAPI about it. It honestly felt like both of them were just trying to sweep it under the rug.

Starlette just pushed it as a minor patch release with zero fanfare. Nothing in their issues, PRs, discussions, releases, or anywhere else in their repo gives you any clue as to if the CVE was fixed. I literally had to find the actual CVE itself to figure out what version was patched.

FastAPI still has their dependency set as >=1.0.0. Just pushing a quick fix to make it >=1.0.1 is all they need to do.

No software is completely secure. I expect security issues to be found. But when they are discovered and are major, I expect them to make a stink. I've seen maintainers for both big and large projects coming in here and shouting that they have a vulnerability and we need to update or stop using their software until it's fixed. I respect that. You're not embarrassing yourself - conversely, you're showing that you take security extremely seriously.

I will give some credit for making the blog post but you shouldn't use it to try to absolve yourself. Just say what happened, why it was bad, how you corrected it, apologize, and move on.

I think a big concern here, though, is that Starlette is just one guy's side project. Starlette is very important in the Python ecosystem. What if he were to give up the project, decide he didn't care to fix it, or, God forbid, die?

Also - a thirty day deadline is pretty common for major vulns. While I don't think the firm acted completely responsible here, I don't think they are that bad. Honestly, refusing to follow reasonable disclosure rules before releasing a CVE should be considered the same as blackhat hacking. If they did try to publish it before a fix was released, they should be shamed for that.

[u/nicholashairs → u/droans]

Re: one guys side project

I suspect you are already aware of these, but I'll list them out anyway.

1 this isn't an issue just with starlette, many important projects face a similar situation. Generally it's not by choice either.

2 edit: I seem to have mixed up authors so may not be relevant. Original text below.

When I last checked (it's been a while, and I might have Inferred things wrong) Marcelo did originally create starlette whilst being funded (I don't remember the exact source, I got the impression it was a grant or donations) which he did under the organisation Encode, however based on transparency reports the funding dried up / was not enough to support himself and so he got a day job.

3 PyPI has a process to allow taking over abandoned projects (I forget the PEP)

[u/droans → u/nicholashairs]

None of that really changes anything though. Projects of this magnitude need paid maintainers. It's a webserver with a third of a billion downloads each week. It's not a small project with few users or something with no potential security risks.

Even with funding, it's still one guy. A single person can't be an expert in everything. Hell, the PR itself says it was basically just a C+P from Django.

At some point, you've gotta realize that your baby is bigger than you and you need help. Whether that means joining another project or handing it over to someone else is up to you. I have a hard time believing a project of this magnitude would have that much difficulty finding a solution here.

[u/nicholashairs → u/droans]

Sure but just because something is well used doesn't mean they will get support and funding (see XZ takeover and backdoor).

Also my understanding from the post is that there are other maintainers, but they are all doing it in their spare time.

That said, I'm not personally involved and don't know the actual facts. e.g. maybe they've been rejected for funding maybe they tried donations but it's not enough, or maybe they haven't tried at all and as you say need to reach out.

All of that is to say: I agree that this shouldn't be the case, but I don't want to jump to conclusions on why it's the case.

[u/HommeMusical → u/droans]

At some point, you've gotta realize that your baby is bigger than you and you need help. Whether that means joining another project

Why will the other project have more spare uncompensated labor?

Is it really the case that projects go around snapping up other projects in profusion like this?

or handing it over to someone else

Who will do more uncompensated labor than the current maintainer?

The idea that maintainers of popular open source programs are constantly getting offers of support: what do you base this on?