← Blog · · df00tech

AnyIO Patches TLSStream Flaw Allowing Certificate Spoofing via IDNA 2003 Encoding (CVE-2026-63374)

breaking ghsa pip CVE-2026-63374

What happened

The maintainers of anyio, the popular Python async I/O library, published a GitHub Security Advisory (GHSA-82r6-8w77-94w6, tracked as CVE-2026-63374) disclosing a weakness in how TLSStream handles internationalized (non-ASCII) domain names. According to the advisory, when a connection is established via connect_tcp() or directly through TLSStream.wrap(), host names are encoded using IDNA 2003 rules. If an attacker has already hijacked the network path and redirected traffic to a malicious server, they could obtain a legitimate certificate for the IDNA 2003 encoded form of the target domain and present it during the TLS handshake — and the client-side validation would accept it as valid.

A fix is planned for anyio v4.14.2. Until upgraded, the advisory recommends encoding host names through the idna package before initiating connections as a workaround. Exploit status is listed as proof-of-concept public.

Why it matters for defenders

This is not a remote-code-execution bug — it's a certificate-validation trust issue that only becomes exploitable in combination with a separate network hijack or redirection (e.g., DNS spoofing, ARP poisoning, or a compromised proxy). Any Python service or client that uses anyio for TLS connections to internationalized domain names is potentially affected, meaning the practical blast radius depends heavily on how widely IDN hostnames are used in your environment and whether an attacker already has some level of network positioning.

What to watch for / do now

  • Inventory applications and services that depend on anyio (directly or transitively via libraries like httpx, trio-based stacks, or async frameworks) and check whether they connect to non-ASCII domain names.
  • Plan to upgrade to anyio v4.14.2 or later once released; until then, apply the documented workaround of pre-encoding hostnames with the idna package.
  • From a hunting perspective, this vulnerability is a downstream consequence of network hijacking — teams should focus detection efforts on the underlying hijack vectors (unexpected DNS resolution changes, unusual TLS certificate issuers for internal or partner IDN domains, and anomalous redirection of outbound TLS sessions) rather than expecting to detect the certificate acceptance itself.
  • Review certificate transparency logs for unexpected certificates issued against IDNA-encoded variants of domains you own or rely on.

Developing intel

This is a same-day advisory and details may evolve as the patched release ships and the community assesses real-world exploitability. For the authoritative technical writeup, see the original GitHub Security Advisory: GHSA-82r6-8w77-94w6.

Get new detections in your inbox

New ATT&CK coverage plus CISA KEV / CVE detection rules, roughly weekly. No spam, unsubscribe anytime.