ECHO-eeb1-df32-dbaa
See a problem?- Import Source
- https://advisory.echohq.com/osv/ECHO-eeb1-df32-dbaa.json
- JSON Data
- https://api.osv.dev/v1/vulns/ECHO-eeb1-df32-dbaa
- Upstream
- CVE-2026-85087
- Withdrawn
- 2026-10-05T18:43:47Z
- Published
- 2026-10-03T09:20:14Z
- Modified
- 2026-10-05T19:30:54Z
- Summary
- 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.
- Details
- References