ssl.SSLContext.wrap_bio() didnt require the server_hostname argument to not be None if ssl.SSLContext.check_hostname was set. Due to a missing parameter check in SSLObject, if the server_hostname argument isnt supplied then hostname verification would be silently skipped.
This defect could lead to programs where certificate hostname verification appeared to be succeeding with SSLContext.check_hostname = True and no ValueError being raised due to misconfiguration.
If the program passes a server_hostname value that isnt an empty string or None to any of these APIs then certificate hostname verification proceeds as expected and the program is not affected by this vulnerability.
Mitigating this vulnerability doesnt require updating Python or applying the patch. To mitigate, pass a valid non-None and non-empty server_hostname value to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls() and certificate hostname verification will proceed as expected. Upgrading to the latest version of Python or applying the patch only changes the behavior from silently skipping hostname verification to raising a ValueError, similar to SSLContext.wrap_socket(), when server_hostname isnt supplied.
Weakness
The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.
Affected Software
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Red Hat Enterprise Linux 10 | RedHat | python3.14-0:3.14.8-1.el10_2 | * |
| Red Hat Enterprise Linux 10 | RedHat | python3.12-0:3.12.15-1.el10_2 | * |
| Red Hat Enterprise Linux 8 | RedHat | python3.12-0:3.12.15-2.el8_10 | * |
| Red Hat Enterprise Linux 9 | RedHat | python3.12-0:3.12.15-1.el9_8 | * |
| Red Hat Enterprise Linux 9 | RedHat | python3.14-0:3.14.8-1.el9_8 | * |
| Red Hat Hardened Images | RedHat | python3-14-main-3.14.7-1.3.hum1 | * |
| Red Hat Hardened Images | RedHat | python3-10-main-3.10.21-1.5.hum1 | * |
| Red Hat Hardened Images | RedHat | python3-11-main-3.11.16-1.5.hum1 | * |
| Red Hat Hardened Images | RedHat | python3-13-main-3.13.15-1.4.hum1 | * |
| Red Hat Hardened Images | RedHat | python3-12-main-3.12.14-1.4.hum1 | * |
Extended Description
Even if a certificate is well-formed, signed, and follows the chain of trust, it may simply be a valid certificate for a different site than the site that the product is interacting with. In order to ensure data integrity, the certificate must be valid, and it must pertain to the site that is being accessed. Even if the product attempts to check the hostname, it is still possible to incorrectly check the hostname. For example, attackers could create a certificate with a name that begins with a trusted name followed by a NUL byte, which could cause some string-based comparisons to only examine the portion that contains the trusted name.
Potential Mitigations
References
- https://github.com/python/cpython/commit/1697ea386c707142555d98a1263176bbbc014a96
- https://github.com/python/cpython/commit/5867d4e4ae6d1062352baf6b497a4026e8578ccf
- https://github.com/python/cpython/commit/641390146a16a38e6701923f4ee4f1940ae77082
- https://github.com/python/cpython/commit/869069d52ce0efab2f8c38197e92cdaaa312f1ed
- https://github.com/python/cpython/commit/966bf426d0b6c31c1b0a255ff14a17143a466ced
- https://github.com/python/cpython/commit/bdebbf9b366ec91e9cd9daa0b3510c9e84b60b80
- https://github.com/python/cpython/commit/f4e43ba525187282f2011da0e6ffc0d2b08d8062
- https://github.com/python/cpython/issues/156793
- https://github.com/python/cpython/pull/158503
- https://mail.python.org/archives/list/security-announce@python.org/thread/QNZRG3YOAMTHDCMVCICXGY6YEFPY2VDL/
- http://www.openwall.com/lists/oss-security/2026/09/30/16