Anyio
Monthly
Silent privilege-separation failure in AnyIO 4.14.0 and 4.14.1 on POSIX: when an application passes extra_groups to anyio.run_process() or anyio.open_process() to drop or clear supplementary groups before launching a less-privileged child, the library forwards the wrong variable (the group argument) to the backend, so an intended extra_groups=[] reset is ignored and the child silently inherits the parent's supplementary groups; if group is also supplied, the integer is passed where an iterable is expected and the launch aborts with TypeError. Impact is limited to local, non-network scenarios and only affects applications that already run with the privileges being dropped (PR:H) and rely on this specific code pattern to establish a privilege-dropping boundary, with no consequence unless the spawned child is subsequently compromised; no public exploit identified at time of analysis.
Denial of service in AnyIO versions prior to 4.14.2: the process-pool implementation behind to_process.run_sync() starts worker processes with stderr wired to a pipe that the parent never drains, so a worker that writes more than the roughly 64 KiB pipe buffer to sys.stderr blocks on write() before it can return its stdout protocol response, leaving the awaiting process-pool call hung indefinitely. Applications are exposed only if they actually use AnyIO's process pool and run worker functions whose stderr volume can be driven by untrusted or faulty input - for example verbose tracebacks or logging produced by attacker-influenced data - while code paths that never touch to_process, or that already close/redirect worker stderr, are unaffected. Impact is limited to availability (hang), with no confidentiality, integrity, or code-execution effect, and per the vendor and independent assessment this is a local, low-privilege-scoped flaw (CVSS:4.0 AV:L/PR:L and CVSS:3.1 AV:L/PR:L, A:H); no public exploit code exists and no active exploitation has been confirmed (no public exploit identified at time of analysis).
Silent privilege-separation failure in AnyIO 4.14.0 and 4.14.1 on POSIX: when an application passes extra_groups to anyio.run_process() or anyio.open_process() to drop or clear supplementary groups before launching a less-privileged child, the library forwards the wrong variable (the group argument) to the backend, so an intended extra_groups=[] reset is ignored and the child silently inherits the parent's supplementary groups; if group is also supplied, the integer is passed where an iterable is expected and the launch aborts with TypeError. Impact is limited to local, non-network scenarios and only affects applications that already run with the privileges being dropped (PR:H) and rely on this specific code pattern to establish a privilege-dropping boundary, with no consequence unless the spawned child is subsequently compromised; no public exploit identified at time of analysis.
Denial of service in AnyIO versions prior to 4.14.2: the process-pool implementation behind to_process.run_sync() starts worker processes with stderr wired to a pipe that the parent never drains, so a worker that writes more than the roughly 64 KiB pipe buffer to sys.stderr blocks on write() before it can return its stdout protocol response, leaving the awaiting process-pool call hung indefinitely. Applications are exposed only if they actually use AnyIO's process pool and run worker functions whose stderr volume can be driven by untrusted or faulty input - for example verbose tracebacks or logging produced by attacker-influenced data - while code paths that never touch to_process, or that already close/redirect worker stderr, are unaffected. Impact is limited to availability (hang), with no confidentiality, integrity, or code-execution effect, and per the vendor and independent assessment this is a local, low-privilege-scoped flaw (CVSS:4.0 AV:L/PR:L and CVSS:3.1 AV:L/PR:L, A:H); no public exploit code exists and no active exploitation has been confirmed (no public exploit identified at time of analysis).