CVE-2026-19553: 
Rocky Linux vulnerability analysis and mitigation

CVE-2026-19553 is a certificate hostname verification bypass vulnerability in CPython's ssl module, specifically in ssl.SSLContext.wrap_bio(). When ssl.SSLContext.check_hostname is set to True, the function failed to require a valid server_hostname argument, causing hostname verification to be silently skipped rather than raising a ValueError when server_hostname is None or omitted. This affects CPython versions prior to 3.10.22, 3.11.17, 3.12.15, 3.13.16, 3.14.8, and 3.15.0rc3, as well as Microsoft's Azure Linux 3 Python 3.12 package. The vulnerability was disclosed on September 30, 2026, with a CVSS v3.1 score of 7.4 (High) and a CVSS v4.0 score of 7.6 (High) (Github Advisory, Red Hat Bugzilla).

The root cause is a missing parameter validation check in SSLObject (CWE-297: Improper Validation of Certificate with Host Mismatch; CWE-295: Improper Certificate Validation). Unlike SSLContext.wrap_socket(), which raises a ValueError when server_hostname is not provided with check_hostname=True, wrap_bio() lacked this guard, causing the underlying SSL handshake to proceed without verifying the server's certificate hostname. The same flaw affects asyncio.create_connection() and asyncio.loop.start_tls() when they internally call wrap_bio() without a server_hostname. The fix, merged in CPython PR #158503 by Seth Larson on September 30, 2026, adds parameter validation to wrap_bio() consistent with wrap_socket(), raising a ValueError (or DeprecationWarning in older branches) when server_hostname is absent (CPython PR, CPython Issue).

Successful exploitation enables a network-based man-in-the-middle (MITM) attacker to present a fraudulent or mismatched TLS certificate that would normally be rejected, bypassing the intended hostname verification security control. This results in high confidentiality and integrity impact — an attacker can intercept and potentially modify encrypted communications between a vulnerable Python application and a remote server without detection. Availability is not directly impacted. Applications using ssl.SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls() without explicitly passing a server_hostname are at risk, which may include TLS-enabled network clients and asyncio-based services (Github Advisory, Red Hat Bugzilla).

A proof-of-concept exploit is publicly available on GitHub (abraxas/cve-2026-19553-wrap-bio), implemented as a Python script with a Docker Compose lab environment that demonstrates the hostname verification bypass by accepting a mismatched certificate (PoC GitHub). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.47%, indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a network-adjacent MITM position and a target application that omits the server_hostname argument, making opportunistic mass exploitation unlikely (Github Advisory).

1. Identify a vulnerable target: Locate a Python application using ssl.SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls() without supplying a server_hostname argument, running on CPython < 3.10.22, 3.11.17, 3.12.15, 3.13.16, or 3.14.8.
2. Position for MITM: Gain a network-adjacent position between the vulnerable Python client and its intended TLS server (e.g., via ARP spoofing, DNS poisoning, or rogue Wi-Fi access point).
3. Intercept the TLS handshake: Intercept the outgoing TLS connection from the vulnerable application using a tool such as mitmproxy or a custom TLS proxy.
4. Present a mismatched certificate: Serve a TLS certificate for a different hostname (e.g., evil.lab instead of the intended target.example.com). Because server_hostname was not passed to wrap_bio(), the Python SSL stack skips hostname verification and accepts the certificate without raising an error.
5. Decrypt and relay traffic: With the MITM TLS session established, decrypt, inspect, or modify the application's encrypted communications before forwarding them to the legitimate server, achieving confidentiality and integrity compromise (CPython Issue, PoC GitHub).

Preferred remediation: Upgrade CPython to a patched version — 3.10.22, 3.11.17, 3.12.15, 3.13.16, 3.14.8, or 3.15.0rc3 or later. Red Hat Enterprise Linux users should apply errata RHSA-2026:77017, RHSA-2026:77018, RHSA-2026:77020, RHSA-2026:77021, or RHSA-2026:77028 as applicable. SUSE users should apply SUSE-SU-2026:4630-1 or SUSE-SU-2026:4659-1. Debian LTS users should apply the update announced in debian-lts-announce for October 2026.

Code-level workaround (no upgrade required): Ensure all calls to ssl.SSLContext.wrap_bio(), asyncio.create_connection(), and asyncio.loop.start_tls() explicitly pass a valid, non-empty, non-None server_hostname argument. This causes hostname verification to proceed correctly regardless of Python version (Red Hat Bugzilla, CPython PR).

The Python Security team (Seth Larson) disclosed the vulnerability via the security-announce@python.org mailing list and coordinated backports across all maintained branches simultaneously with the September 30, 2026 release of Python 3.10.22, 3.11.17, 3.12.15, 3.13.16, and 3.14.8. The issue was labeled a release-blocker in the CPython issue tracker, reflecting the Python core team's assessment of its severity. Red Hat, SUSE, Debian, AlmaLinux, and Oracle Linux all issued security advisories and updated packages within days of disclosure, indicating broad downstream attention. Security media outlets including SecurityOnline.info and LinuxCompatible.org covered the release, noting that Python 3.10 simultaneously reached end-of-life with this security update (CPython PR, Red Hat Bugzilla).