Is anyio safe ? 3 known vulnerabilities, worst severity CRITICAL.
// reach 5 direct dependencies
1 carry known advisories, worst MEDIUM
281 packages depend on it
an advisory here reaches each of them
// ai model usage No published models are known to use this package.
cvss CVSS v4.0 base score out of 10
epss chance of exploitation in 30 days, 22nd percentile of all CVEs
xyz score CyberXYZ composite out of 10
fig. 01 — GHSA-82r6-8w77-94w6, the advisory selected below
// 3 advisories GHSA-82r6-8w77-94w6 Services using internationalized (non-ASCII) domain names are potentially vulnerable to TLS connections made from AnyIO's connect_tcp() 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 connec CRIT GHSA-3w57-8xmc-8v26 AnyIO 4.14.0 accepts the POSIX extra_groups argument on anyio.run_process() and anyio.open_process(), but open_process() forwards the wrong variable to the backend: when extra_groups is not None, it assigns kwargs["extra_groups"] = group instead of extra_groups. As a result, callers cannot reliably clear or set supplementary groups for child processes. In a disposable Linux container, Python's sub HIGH GHSA-5p39-cfhj-2xmp AnyIO starts process-pool workers with stderr connected to a pipe but never drains that pipe. The worker redirects stdin and stdout to /dev/null to protect its protocol, but does not redirect stderr even though the documentation says all three standard streams are redirected. Worker code that writes enough attacker-influenced data to stderr can fill the pipe, block before returning the stdout prot MODE // impact Services using internationalized (non-ASCII) domain names are potentially vulnerable to TLS connections made from AnyIO's connect_tcp() 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.
// cvss v4.0 vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Attack vector Network
Attack complexity Low
Attack requirements None
Privileges required None
User interaction None
Confidentiality (vulnerable system) High
Integrity (vulnerable system) High
Availability (vulnerable system) None
Confidentiality (subsequent systems) None
Integrity (subsequent systems) None
Availability (subsequent systems) None Checked 2026-11-06 at 21:45 UTC. The most recent advisory here was published 2026-09-18. Updated continuously from NVD, GHSA, OSV and CNA feeds.
Think a verdict here is wrong? Tell us — we respond within 2 business days. Report an issue with this page