CVE-2026-63374: 
Python vulnerability analysis and mitigation

CVE-2026-63374 is a TLS certificate validation bypass vulnerability in the AnyIO Python library affecting all versions prior to 4.14.2. The flaw exists in connect_tcp() and TLSStream.wrap(), which incorrectly encode internationalized (non-ASCII) domain names using IDNA 2003 (via Python's standard library) instead of the correct IDNA 2008 standard. This mismatch can cause a hijacked TLS connection to a malicious server to pass certificate validation if the attacker presents a legitimate certificate obtained using the IDNA 2003-encoded form of the target domain. It was first disclosed by the project maintainer on July 7, 2026, and carries a CVSS v4 base score of 9.3 (Critical) (GitHub Advisory, AnyIO Security Advisory).

The root cause is improper certificate validation (CWE-295) and improper validation of certificate with host mismatch (CWE-297). When TLSStream.wrap() receives a Unicode hostname, it passes it directly to Python's ssl.SSLContext.wrap_bio(), which internally encodes it using IDNA 2003. For certain internationalized domain names, IDNA 2003 and IDNA 2008 produce different ASCII encodings — for example, faß.de encodes to fass.de under IDNA 2003 but to xn--fa-hia.de under IDNA 2008. An attacker who has already redirected the TCP connection (e.g., via DNS hijacking or ARP spoofing) can obtain a legitimate CA-signed certificate for the IDNA 2003 form of the domain and present it, causing the client's TLS validation to succeed against the wrong certificate. The fix (commit 68f5891) introduces an idna2008_resolve() helper that uses the idna Python package to encode hostnames before passing them to the TLS layer (AnyIO Commit, AnyIO PR #1208).

Successful exploitation enables a man-in-the-middle (MitM) attack against TLS-protected communications targeting services with internationalized domain names. The attacker can intercept and read encrypted traffic (high confidentiality impact) and potentially inject or modify data in transit (high integrity impact). Availability is not directly affected. The scope is limited to applications using AnyIO's connect_tcp() or TLSStream.wrap() with non-ASCII hostnames, but the impact on affected connections is complete — all data exchanged over the spoofed TLS session is exposed to the attacker (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the advisory date (GitHub Advisory). Exploitation requires a precondition: the attacker must first be able to redirect or hijack the TCP connection (e.g., via DNS poisoning, BGP hijacking, or network-level MitM), limiting opportunistic exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog, and no threat actor attribution has been reported. No EPSS score is currently available given the CVE's reserved status.

1. Identify a target: Find an application using AnyIO (versions < 4.14.2) that connects to a service via an internationalized (non-ASCII) domain name, such as faß.de.
2. Determine IDNA encoding discrepancy: Identify domain names where IDNA 2003 and IDNA 2008 produce different encodings. For example, faß.de → fass.de (IDNA 2003) vs. xn--fa-hia.de (IDNA 2008). Tools like the Python idna package can enumerate these differences.
3. Obtain a legitimate certificate: Acquire a valid CA-signed TLS certificate for the IDNA 2003-encoded form of the target domain (e.g., fass.de). This is a standard domain registration and certificate issuance process.
4. Redirect the victim's connection: Use a network-level attack (DNS cache poisoning, ARP spoofing, BGP hijacking, or rogue Wi-Fi) to redirect the victim application's TCP connection to an attacker-controlled server.
5. Present the spoofed certificate: Configure the malicious server to present the IDNA 2003-encoded certificate. The vulnerable AnyIO client will validate the certificate against the IDNA 2003 encoding of the hostname and accept it as valid.
6. Intercept communications: With TLS established to the malicious server, decrypt, read, and optionally modify all traffic the victim application believes is securely sent to the legitimate service (AnyIO Security Advisory, AnyIO Commit).

• Network: Unexpected TLS certificate presented for a domain that differs from the expected IDNA 2008 encoding (e.g., certificate CN/SAN shows fass.de when connecting to faß.de); TLS connections to unexpected IP addresses for internationalized domain names.
• Logs: Application logs showing successful TLS handshakes to IP addresses not associated with the legitimate service's DNS records; certificate details in TLS inspection logs showing IDNA 2003-encoded hostnames instead of IDNA 2008 equivalents.
• Network: Anomalous DNS responses returning attacker-controlled IPs for internationalized domain names; ARP cache entries pointing to unexpected MAC addresses for gateway or DNS servers (indicative of ARP spoofing used to enable the MitM).

Upgrade AnyIO to version 4.14.2 or later, which corrects TLSStream.wrap() to use IDNA 2008 encoding via the idna Python package (AnyIO Release 4.14.2). As an immediate workaround for environments that cannot upgrade, pre-encode hostnames using the idna package before passing them to connect_tcp() or TLSStream.wrap() (e.g., idna.encode(host, uts46=True)) (GitHub Advisory). Organizations should also apply network-level controls such as DNSSEC validation and network monitoring to reduce the risk of the prerequisite connection hijacking.

The vulnerability was disclosed and patched by AnyIO maintainer agronholm on July 7–8, 2026, with the fix merged via PR #1208 and released in v4.14.2 on July 12, 2026. A collaborator (tapetersen) reviewed and approved the fix, noting the test case using faß.de was illustrative of the IDNA encoding discrepancy. At least one downstream project (too-good-to-go/conductor) has already merged a dependency upgrade to AnyIO 4.14.2 in response (AnyIO PR #1208).