CVE-2026-63349 in AnyIO
Summary
by MITRE • 09/18/2026
AnyIO is a high level asynchronous concurrency and networking framework that works on top of either Trio or asyncio. In 4.14.0, AnyIO accepts the POSIX extra_groups argument in anyio.run_process() and anyio.open_process(), but open_process() forwards the group argument to the backend instead of extra_groups. A caller that supplies extra_groups=[] to clear inherited supplementary groups can therefore launch a child that retains the parent process groups, undermining a privilege-dropping boundary. If group is also supplied, the integer group value is passed where an iterable of supplementary groups is expected and the launch can fail with TypeError. This issue affects POSIX applications that rely on AnyIO subprocess helpers to launch less-privileged child processes. This issue is fixed in version 4.14.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in AnyIO versions prior to 4.14.2 represents a critical logic error within the asynchronous process management utilities, specifically affecting the open_process function on POSIX-compliant operating systems. AnyIO serves as a high-level abstraction layer for asynchronous concurrency and networking, supporting both Trio and asyncio backends. In version 4.14.0, developers introduced support for the extra_groups argument in both run_process and open_process functions to allow callers to specify supplementary group IDs when launching child processes. This feature is essential for security-conscious applications that need to drop privileges or isolate execution contexts by altering the process group membership of spawned tasks. However, a parameter mapping error was introduced during this implementation where the open_process function incorrectly forwards the positional argument intended for extra_groups to the backend as the single integer group identifier rather than the iterable list of supplementary groups.
This misconfiguration leads to two distinct operational failures depending on how the caller utilizes these functions. First, if an application attempts to clear inherited supplementary groups by passing an empty list via the extra_groups parameter, the flawed logic causes open_process to ignore this instruction or mishandle it, resulting in child processes that retain the parent process's group memberships. This undermines a fundamental privilege-dropping boundary, as security models often rely on restricting supplementary groups to limit access to specific resources such as files, sockets, or inter-process communication channels. By retaining elevated or unnecessary group privileges, the child process operates with a broader attack surface than intended, potentially allowing unauthorized access to sensitive system components that should have been restricted by the parent's isolation strategy.
Second, if a caller supplies both the positional group argument and the extra_groups keyword argument, the function attempts to pass an integer value into a context expecting an iterable of supplementary groups within the backend implementation. This type mismatch triggers a TypeError exception during process launch, causing immediate failure of the asynchronous operation. While this results in availability issues rather than direct exploitation, it indicates poor input validation and can lead to unexpected crashes in production environments that rely on these subprocess helpers for critical background tasks or service orchestration. The issue specifically impacts POSIX applications because Windows does not utilize supplementary groups in the same manner, making this vulnerability specific to Unix-like operating systems where group-based access control is a primary security mechanism.
From a classification perspective, this flaw aligns with CWE-20 Improper Input Validation and CWE-787 Out-of-bounds Write if interpreted broadly as memory safety issues, though more accurately it falls under CWE-691 Insufficient Control Flow Management or logic errors in parameter handling. In the context of the MITRE ATT&CK framework, this vulnerability relates to Tactic TA0004 Privilege Escalation and Technique T1548 Abuse Elevation Control Mechanism, as an attacker who can influence process launch parameters might exploit the retained group memberships to access restricted resources or escalate privileges within a compromised container or service. The failure to properly isolate supplementary groups violates the principle of least privilege, which is central to secure system design.
To mitigate this vulnerability, organizations and developers must immediately upgrade AnyIO to version 4.14.2 or later, where the parameter forwarding logic has been corrected to ensure that extra_groups are correctly passed as an iterable to the backend implementation. For applications currently running on affected versions, it is imperative to audit all calls to open_process for incorrect usage of group and extra_groups parameters. Developers should implement strict input validation in their own code layers if upgrading is not immediately feasible, ensuring that supplementary groups are handled explicitly and consistently across both run_process and open_process invocations. Additionally, security teams should review subprocess launch configurations in asynchronous applications to verify that privilege dropping mechanisms function as intended by testing group membership retention after process creation.