CVE-2026-64847: 
Python vulnerability analysis and mitigation

CVE-2026-64847 is a denial-of-service vulnerability in AnyIO, a high-level asynchronous concurrency and networking framework for Python, titled "AnyIO process-pool workers can block indefinitely on undrained stderr." It affects all versions of the anyio pip package prior to 4.14.2. The vulnerability was originally published on July 7, 2026, and added to the GitHub Advisory Database on September 18, 2026. It carries a CVSS v4.0 base score of 6.8 (Medium) (Github Advisory).

The root cause is classified as CWE-770 (Allocation of Resources Without Limits or Throttling). AnyIO's to_process.run_sync() spawns process-pool worker subprocesses with stderr connected to a pipe, but the parent process never drains that pipe. While the worker correctly redirects stdin and stdout to /dev/null to protect its IPC protocol, stderr is left connected to the undrained pipe — contradicting the documented behavior that all three standard streams are redirected. If worker code writes enough data to sys.stderr (e.g., more than the typical 64 KiB OS pipe buffer), the write blocks, preventing the worker from ever sending its stdout protocol response, which causes the awaiting to_process.run_sync() call in the parent to hang indefinitely. The fix, applied in commit f1b7301, adds a single line redirecting sys.stderr to os.devnull within the worker process (Github PR #1207, Github Commit).

Successful exploitation causes an indefinite deadlock in the affected process-pool worker and the awaiting coroutine, resulting in a denial of service against the application's availability. There is no impact on confidentiality or integrity — the vulnerability is purely an availability issue. Applications that execute untrusted or faulty worker code capable of generating substantial stderr output are most at risk, as a blocked worker can exhaust the process pool and render the application unresponsive (Github Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The EPSS score is 0.0, and the NVD SSVC assessment classifies exploitation as "none" and the vulnerability as not automatable (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires local access and low privileges — specifically, the ability to supply or influence worker code that writes large volumes of data to sys.stderr.

1. Identify a target application: Locate an application using AnyIO versions prior to 4.14.2 that calls to_process.run_sync() with worker functions whose stderr output can be influenced by attacker-controlled input.
2. Craft a stderr-flooding payload: Prepare or influence the worker function to write a large volume of data (well exceeding the OS pipe buffer, typically 64 KiB) to sys.stderr. For example, a payload such as sys.stderr.write('x' * 1024 * 1024); sys.stderr.flush() within the worker function would suffice.
3. Trigger the worker execution: Cause the application to invoke to_process.run_sync() with the crafted or influenced worker function, either by submitting malicious input or exploiting a code path that passes attacker-influenced data to stderr.
4. Induce deadlock: The worker's stderr write fills the undrained pipe buffer and blocks. The worker never sends its stdout protocol response, causing the parent's run_sync() awaitable to hang indefinitely, effectively deadlocking that worker slot.
5. Exhaust the process pool: Repeat the trigger to fill all available worker slots, rendering the application's process pool fully blocked and causing a complete denial of service (Github Advisory, Github PR #1207).

• Process Behavior: AnyIO worker subprocesses that remain in a blocked/sleeping state indefinitely without completing their assigned task; parent asyncio or Trio event loop tasks stuck awaiting to_process.run_sync() with no timeout.
• Logs: Application logs showing to_process.run_sync() calls that never return or time out; absence of expected task completion log entries from process-pool workers.
• System: Elevated number of zombie or hung child processes associated with the Python application; OS-level pipe buffers for the application's worker subprocesses consistently at capacity (observable via /proc/<pid>/fd on Linux).

Upgrade the anyio pip package to version 4.14.2 or later, which redirects sys.stderr to os.devnull in worker processes, matching the documented behavior and eliminating the deadlock (Github Release 4.14.2). As a temporary workaround for those unable to upgrade immediately, explicitly closing sys.stderr at the start of the target function passed to to_process.run_sync() will prevent the deadlock by ensuring writes do not block on the pipe (Github Advisory). Additionally, avoid passing untrusted or unvalidated code as worker functions to to_process.run_sync() until the patch is applied.