The vulnerable code postdates this version. The Python >= 3.12 no-op host-name matcher (sslcompat returning True when ssl.match_hostname is missing) was introduced by 23e0e5ce (first released in 0.22.

The vulnerable code postdates this version. The Python >= 3.12 no-op host-name matcher (sslcompat returning True when ssl.match_hostname is missing) was introduced by 23e0e5ce (first released in 0.22.0) and is not an ancestor of v0.19.0. On trixie's Python 3.13 this version's sslcompat falls back to legacy_validate_callback, which compares the certificate commonName and raises on a mismatch; TSSLSocket uses PROTOCOL_SSLv23 (the PROTOCOL_TLS alias) with check_hostname off, so that callback is the check that runs. Verified with real handshakes against the built lib on Python 3.13.5: a certificate for "localhost" offered to a client expecting "wrong.example" is refused with the default ssl_version, with an explicit PROTOCOL_TLS (the upstream regression case) and with PROTOCOL_TLSv1_2, and TSSLServerSocket refuses a trusted client certificate issued for another identity. The same script against upstream v0.24.0's lib accepts both explicit-ssl_version mismatches, as the CVE describes. The fix d6782a87 restores a real matcher in sslcompat (code this version never lost) and turns on check_hostname for explicit-ssl_version contexts, which 0.19.0 does not need because open() always runs _validate_callback. Same reasoning as CVE-2026-66053.