CVE-2026-63374: AnyIO: TLSStream IDNA 2003 host name encoding enables potential TLS certificate spoofing
Impact Services using internationalized (non-ASCII) domain names are potentially vulnerable to TLS connections made from AnyIO's connecttcp() or directly via TLSStream.wrap() where the connection has (through other means) been hijacked and redirected to a malicious server. The attacker would obtain a legitimate certificate using the IDNA 2003 encoded version of the domain name and offer it to the connecting client, making the certificate validate properly on the client's end.
Patches The vulnerability will be patched in v4.14.2.
Workarounds Encode host names via the idna package prior to connecting.
Other sources
AnyIO is a high level asynchronous concurrency and networking framework that works on top of either Trio or asyncio. Prior to 4.14.2, connecttcp() and TLSStream.wrap() can validate internationalized host names after the standard library converts them with IDNA 2003 instead of IDNA 2008. When a connection to a non-ASCII domain is hijacked or redirected, an attacker can obtain a legitimate certificate for the different ASCII hostname produced by IDNA 2003 and present it to the client, causing the malicious endpoint's certificate to validate. This issue is fixed in version 4.14.2.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/anyioto a version that resolves this vulnerability.Fixed in 4.14.2 - Upgrade
Upgrade
AnyIOto a version that resolves this vulnerability.Fixed in 4.14.2 - Compensating control
Encode internationalized host names via the idna package before connecting.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Services are potentially exposed when they connect to internationalized, non-ASCII domain names using AnyIO's connect_tcp() or TLSStream.wrap(). Exploitation additionally requires the connection to be hijacked and redirected to an attacker-controlled server.
What does an attacker need to make certificate validation succeed?
The attacker needs a legitimate certificate for the IDNA 2003-encoded form of the target internationalized domain name. They can then present that certificate from the malicious server after redirecting the connection.
What can be done before upgrading?
Encode host names with the idna package before establishing the connection. The issue is slated to be patched in version 4.14.2.