Yess, I've seen you had merged a change to allow higher pyOpenSSL versions than 25.3.0 just one day after the release. This is the commit I am referring to:

• 79e8bd7

In theory, because of this constraint, mitmproxy kinda exposes you to these two CVE vulnerabilities:

• https://www.cvedetails.com/cve/CVE-2026-27459/ (this one is marked critical)
• https://www.cvedetails.com/cve/CVE-2026-27448/

Of course, you can just override it (or have separate environments etc. if you – whatever the reason – would need multiple versions of that library). But what concerns me is that because Mitmproxy's requirements are strict, package managers will make sure they prevail over some other relaxed ones, regardless of these versions being outdated or vulnerable, and regardless of whether mitmproxy even needs the older implementations. So if you are not integrated with proper vulnerability scanning systems, you may not even know that mitmproxy delivered malicious dependency to your system.

I fully understand your point in that mitmproxy does not specifically rely on the DTLS logic this vulnerability pertains to. But what is very probable is for the same pyOpenSSL version (that was resolved based on these strict constraints) to be used by some other part of your system that would, actually, use that problematic callback logic, and would then entail the actual risk of that buffer overflow problem affecting your system.

I don't want to interfere in your deployment processes, ofc, but that's my opinion so I wanted to share. 😅 Thank you for such a quick response btw 😄

But what is very probable is for the same pyOpenSSL version (that was resolved based on these strict constraints) to be used by some other part of your system that would, actually, use that problematic callback logic, and would then entail the actual risk of that buffer overflow problem affecting your system.

Is that actually the case? I don't know much about the Python ecosystem, but this

to be used by some other part of your system

sounds like a terrible flaw in how versions are resolved, no? What you're implying is that a different software on your system is using pyOpenSSL and pins it to the fixed version but for some reason the version that mitmproxy pulls is used? How does that work in practice?

How are you installing mitmproxy that this would ever be a system wide problem?