CVE-2026-64847: Indefinite Denial of Service via Undrained Stderr in AnyIO Process Pool Workers

AnyIO is an asynchronous concurrency framework for Python that abstracts compatibility over either Trio or asyncio. The framework provides utility interfaces to run synchronous execution units inside process pools using the to_process.run_sync() method. This abstraction coordinates execution by establishing inter-process communication (IPC) channels between the parent event loop and the spawned worker process.

During normal operation, the parent process monitors standard streams to read execution outcomes and serialize protocol inputs. The vulnerability, designated as CVE-2026-64847, lies in the handling of the standard error stream (sys.stderr) inside the worker processes. Although standard streams are documented to be safely isolated, standard error is left connected to a parent-owned operating system pipe.

Because the parent process does not active read or drain the standard error pipe during worker execution, any output routed to stderr persists in the pipe's internal kernel buffer. This lack of resource drainage introduces an immediate vulnerability where standard tracebacks, debug logging, or third-party print statements can fill the kernel buffer and stall execution.

The underlying vulnerability represents a failure to throttle or drain allocated operating system pipe buffers, classified as CWE-770. On modern kernel architectures, inter-process communication pipes employ finite ring buffers managed directly by the kernel. Under standard Linux configurations, this pipe buffer size defaults to 64 KiB (65,536 bytes), while Windows systems dynamically allocate similarly constrained resources.

When a child process outputs data to a standard pipe, the kernel buffers the payload until the parent process executes a read system call. If the child process writes a volume of data exceeding the buffer capacity, and the parent process is not actively draining the pipe, the operating system kernel blocks the writing thread. The writer process transitions into an uninterruptible sleep state waiting for buffer clearance.

In AnyIO versions prior to 4.14.2, the parent process awaits execution results from standard output (sys.stdout) while ignoring standard error (sys.stderr). If the worker process generates more than 64 KiB of diagnostic data on stderr, the write calls block. Consequently, the worker process stalls midway, and the parent process blocks indefinitely waiting for the worker to finish, creating a permanent deadlock.

The sequential flow of the deadlock condition highlights the blockages occurring on both sides of the inter-process pipe.

As the diagram demonstrates, the deadlock state cannot resolve itself because neither process can advance. The worker process cannot complete its execution loop to write a success token to the stdout pipe, and the parent process does not read from the stderr pipe that is blocking the worker.

The bug resides in process_worker() located within src/anyio/to_process.py. In affected versions of AnyIO, the worker initialization routine actively redirects standard input and standard output to null devices to avoid protocol pollution but leaves standard error unhandled.

# Vulnerable Implementation (Pre-4.14.2)
def process_worker() -> None:
    stdout = sys.stdout
    sys.stdin = open(os.devnull)
    sys.stdout = open(os.devnull, "w")
    # sys.stderr is completely omitted and remains connected to the parent pipe!
 
    stdout.buffer.write(b"READY\n")
    while True:
        # Worker loop waiting for payload

To remediate the vulnerability, the standard error stream must be redirected to os.devnull alongside the standard output stream. The fix merged in commit f1b7301c8264b0d2e8d24a5788fd29e93dea4040 implements this behavior:

# Patched Implementation (4.14.2)
def process_worker() -> None:
    stdout = sys.stdout
    sys.stdin = open(os.devnull)
    sys.stdout = open(os.devnull, "w")
    sys.stderr = open(os.devnull, "w") # Safe redirection of standard error
 
    stdout.buffer.write(b"READY\n")
    while True:
        # Worker loop waiting for payload

With this single-line modification, any diagnostic messages, warnings, or debug statements emitted during execution are discarded by the kernel, preventing pipe buffer saturation.

Exploiting this deadlock requires the ability to influence input parsed by the process pool worker, causing it to write verbose output to the standard error stream. This threat model is common in systems executing user-submitted scripts or parsing malicious inputs that trigger expansive logging or tracebacks.

An attacker can trigger the vulnerability by supplying input that forces deep recursive errors, validation warning logs, or direct diagnostic dumps. In configurations allowing untrusted code execution, a simple script writing directly to sys.stderr is sufficient to fill the 64 KiB buffer.

A typical proof-of-concept payload targeting vulnerable implementations is structured as follows:

import anyio
import sys
from anyio import to_process
 
def malicious_worker():
    # Generate a payload larger than the 64 KiB OS pipe buffer
    payload = "X" * (100 * 1024)
    sys.stderr.write(payload)
    sys.stderr.flush() # This call blocks indefinitely under AnyIO < 4.14.2
    return "success"
 
async def main():
    print("[*] Dispatching process pool worker...")
    # The execution will freeze indefinitely here without timeout configuration
    await to_process.run_sync(malicious_worker)
 
if __name__ == "__main__":
    anyio.run(main)

When executed on a vulnerable system, the parent process remains blocked indefinitely during the run_sync call.

The security impact of CVE-2026-64847 is focused exclusively on the availability of the target system, carrying a CVSS score of 6.8. Successful exploitation results in a persistent denial-of-service condition affecting the application pool.

Because AnyIO is a foundational library for high-throughput asynchronous applications, a single blocked worker process can rapidly consume available worker slots in the application process pool. Once the process pool is exhausted, any subsequent requests requiring subprocess isolation will hang, causing wider application degradation.

The attack vector is local (AV:L), meaning the attacker must be capable of executing code or triggering input-driven errors within the worker context. The vulnerability does not present potential for privilege escalation, confidentiality loss, or integrity compromise.

The recommended remediation path is upgrading the AnyIO installation to version 4.14.2 or newer, which completely closes the vulnerable code path by redirecting worker sys.stderr streams.

If upgrading is not immediately possible, developers can implement programmatic mitigation within the synchronous execution unit itself. Manually redirecting sys.stderr to a null target during task startup ensures safety:

import os
import sys
 
def safe_worker_context():
    original_stderr = sys.stderr
    sys.stderr = open(os.devnull, "w")
    try:
        # Execute standard application logic here
        pass
    finally:
        sys.stderr.close()
        sys.stderr = original_stderr

Additionally, defense-in-depth measures should include enforcing strict timeouts using anyio.fail_after() when waiting on process pool tasks to prevent infinite application hangs.