CVE-2026-64847: AnyIO process-pool workers can block indefinitely on undrained stderr
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.
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, AnyIO starts process-pool workers with standard error connected to a pipe that the parent never drains, even though the documented behavior redirects all three standard streams. Worker code that writes enough attacker-influenced data to sys.stderr can fill the pipe and block before returning the standard-output protocol response, causing the awaiting process-pool call to remain blocked indefinitely. Applications that run untrusted or faulty worker code capable of producing substantial standard-error output are affected. 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 - Configuration
In the target function, close sys.stderr to prevent the process-pool deadlock caused by an undrained stderr pipe.
AnyIO process-pool worker function stderr handling = Close sys.stderr
Event History
Frequently Asked Questions
Which applications are most likely to be affected?
Applications using AnyIO process-pool workers prior to version 4.14.2 are at risk when worker code can produce large amounts of stderr output. This includes workloads that execute untrusted code or code that may fail noisily.
What must happen for an attacker or faulty workload to trigger the issue?
The process-pool target must write enough attacker-influenced or otherwise excessive data to sys.stderr to fill the worker's stderr pipe. Once full, the worker can block before sending its protocol response, leaving the awaiting process-pool call wedged.
What can be done if upgrading is not immediately possible?
Closing sys.stderr in the target function should at least prevent the deadlock. Upgrade to AnyIO 4.14.2 when possible.