Upgrade h11 due to vulnerability

[aviad-dev]

Summary

A known vulnerability exists in h11, which is a dependency: https://github.com/advisories/GHSA-vqfr-h8mv-ghfj

Checklist

• [x] I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• [x] ~I've added a test for each change that was introduced, and~ I tried as much as possible to make a single atomic change.
• [ ] ~I've updated the documentation accordingly.~

[aviad-dev]

Hey all. This PR has 1 test failing. To debug this I created what I see as an "empty" (as in - has no changes) PR, where the same test failed (in a different python version, running on macos): https://github.com/encode/uvicorn/actions/runs/15459892624/job/43518913721?pr=2644

I'm not sure what this means, but might imply an issue with the test.

[Kludex]

As I mentioned before, and I've actually consulted a security expert in the ecosystem... This is NOT needed on uvicorn.

The point is that uvicorn already allows you to bump h11 on your application, and the vulnerability was in a dependency.

As a user, you should have a security auditing process to make sure you bump h11.

---

I'll leave this open for a bit - I may merge if a lot of people complain. 🤷‍♂️

[aviad-dev]

Hey @Kludex - thank you for replying. I agree that a user can upgrade h11 on her project, as we’ve done on ours that is using uvicorn. The argument for deploying this small change to uvicorn, in my view, is preventing users that are not auditing their cosebase (or auditing it infrequently) from being exposed, making the Internet safer, one step at a time.

thank you for maintaining this project - it is wonderful! (with and without this pr ;)

[rrees]

I think it would be great to merge this as other security tools that are scanning the stated dependencies of the project rather than perhaps lockfiles will continue to report the package as vulnerable generating unnecessary noise. It would also simplify things for new users by getting them started with a dependency that hasn't been flagged as vulnerable

[zanieb]

This is the same discussion as https://github.com/encode/httpx/pull/3564#issuecomment-2858720787

If users are not auditing their codebase and upgrading uvicorn, they won't see a version bump here regardless.

New users should not get the old vulnerable h11 version, all the Python package resolvers I know of default to using the latest compatible version of dependencies.

[rrees]

So whatever the technical rights or wrongs CodeQL (for example) is flagging this package as having a Critical vulnerability and if updating the metadata helps avoid having to explain why this is a false positive isn't a net win for everyone?

[zanieb]

It's not a net win for users that need to use an older version of h11 and are then needlessly blocked from upgrading uvicorn. This sounds like a problem with CodeQL — it seems absurd to flag this package as having a critical vulnerability because it allows you to install it alongside a vulnerable package version. For example, you can pip install h11<0.16, is that a critical vulnerability in pip?

[aviad-dev]

@zanieb - what you're saying makes sense. In your opinion, under what circumstances is it appropriate to update a dependency requirement version in uvicorn?

[Kludex]

@zanieb - what you're saying makes sense. In your opinion, under what circumstances is it appropriate to update a dependency requirement version in uvicorn?

When needed. If I need to use h11.potato, and h11.potato is introduced in version 0.banana.0, then I need to pin >=0.banana.0.

[aviad-dev]

@Kludex - what about a case when you know uvicorn is certainly introducing a vulnerability (say you require h11==0.vulnerable.0? This is NOT the case we are discussing here, of course.

[Kludex]

@Kludex - what about a case when you know uvicorn is certainly introducing a vulnerability (say you require h11==0.vulnerable.0? This is NOT the case we are discussing here, of course.

Well... If the restriction FORCES the user to install a vulnerable package to use uvicorn, then the bump is also needed...

---

This is not relevant here tho... 👀

[aviad-dev]

I think we’ve clarified the different perspectives:

1. If uvicorn itself directly introduces a vulnerability, then the vulnerable dependency should be updated; otherwise, it shouldn’t be.
2. If uvicorn permits a vulnerability to be introduced indirectly (for example, via user code or another dependency the user relies on), then the dependency should be updated.

You consider the first approach the best policy.

[Kludex]

You consider the first approach the best policy.

This is not about me.

---

This comment reflects my thoughts: https://github.com/encode/uvicorn/pull/2643#issuecomment-2964060293

[aviad-dev]

I meant - under this policy, it makes sense to not merge this PR.

[aviad-dev]

Regarding this comment:
In most cases, uvicorn merely "allows you to install it alongside a vulnerable package version." However, there are certain edge cases where uvicorn itself might end up being the reason a vulnerable package remains installed.

Example of such a (rare) case:

1. You install Package X (not uvicorn), which requires a specific, vulnerable version of h11.
2. Later, you install uvicorn, which doesn’t alter the existing h11 version.
3. Package X is then removed, leaving only uvicorn, which continues using the vulnerable version of h11 without triggering an upgrade.

In this situation, uvicorn becomes the cause, rather than just a bystander. Another option: an old installation of uvicorn caused a vulnerable h11 version to be installed, and the users did not upgrade since.

Having said all that, these scenarios do not invalidate the original considerations—for instance, the desire to let users who need an older version of h11 continue upgrading uvicorn. This simply highlights that there are tradeoffs involved, as we’re all aware.

Personally, I would lean toward a more “secure” or “restrictive” approach, but I recognize that the alternative is a valid and reasonable policy as well. Ultimately, I believe these decisions are best made by the maintainers, not by commenters like myself.

[zanieb]

In this situation, uvicorn becomes the cause, rather than just a bystander.

How is uvicorn the cause? The cause is that the user installed the earlier package, then didn't take the time to upgrade their environment in the future.

If this pull request was merged, and the user were to install uvicorn in your scenario, they'd just end up with an older version of uvicorn and be in the same situation?

[Kludex]

I'll close this for house-keeping.

There's no vulnerability from Uvicorn's side here.