Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
AnyIO 4.14.0 accepts the POSIX extragroups argument on anyio.runprocess() and anyio.openprocess(), but openprocess() forwards the wrong variable to the backend: when extragroups is not None, it assigns kwargs["extragroups"] = group instead of extragroups. As a result, callers cannot reliably clear or set supplementary groups for child processes. In a disposable Linux container, Python's subprocess.run(..., extragroups=[]) clears a synthetic parent supplementary group list, while anyio.runprocess(..., extragroups=[]) preserves the parent groups. If group is also supplied, AnyIO passes an integer as extragroups and the call fails with TypeError. This is a POSIX privilege-dropping correctness issue for applications that rely on AnyIO subprocess helpers to launch less-privileged child processes.
Recommended action: Upgrade to 4.14.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.14.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 protocol response, and wedge the awaiting process-pool call. Anyone who runs untrusted or faulty code that writes too much to stderr is at risk. Patches This vulnerability will be patched in v4.14.2. Workarounds Closing sys.stderr in the target function should at least prevent the deadlock.
Recommended action: Upgrade to 4.14.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.