· via dev.to (home feed)
CVE-2026-63349: AnyIO subprocess typo breaks privilege dropping in versions 4.14.0 and 4.14.1
A one-line variable typo in AnyIO 4.14.0 and 4.14.1 discards the extra_groups setting, so subprocesses keep the parent's elevated supplementary groups. CVE-2026-63349 (CVSS 7.0) is fixed in 4.14.2.

A typo in a single variable name has earned a high severity rating: CVE-2026-63349 describes a privilege-dropping bypass in AnyIO, the Python asynchronous library, affecting versions 4.14.0 and 4.14.1 on POSIX systems. According to a CVE report published on dev.to, the flaw carries a CVSS v4.0 score of 7.0 (High), was published on 18 September 2026, and is fixed in AnyIO 4.14.2.
How the bug works
The affected component is anyio._core._subprocesses. When developers spawn a child process with AnyIO's open_process, they can pass a group argument plus an extra_groups argument to control which primary and supplementary groups the new process holds — a standard way to run less-trusted work with reduced privileges.
The fix, commit eb562e6 ("Fix typo in extra_groups parameter propagation"), changes one line: the code had been assigning kwargs["extra_groups"] = group, which writes the primary-group value into the supplementary-groups slot. The corrected line assigns extra_groups as intended.
The consequence, per the report, is that the supplementary groups a developer specifies never reach the execution backend. The subprocess instead retains the parent process's supplementary group memberships, including potentially powerful ones. Crucially, nothing errors out: the API call succeeds, the process starts, and the privilege reduction the caller asked for simply never happens.
Scope and severity
The write-up scopes the issue to AnyIO versions 4.14.0 and 4.14.1 (that is, >= 4.14.0 and < 4.14.2) on POSIX platforms, with 4.14.2 as the fixed release. It maps the flaw to CWE-266 and CWE-269, covering incorrect privilege assignment and improper privilege management, rates the attack vector as local, and lists exploit status as proof-of-concept/theoretical. The issue is not in the CISA KEV catalog. The report's headline also mentions denial of service, though the technical detail it publishes concerns the privilege-dropping bypass.
The report names groups such as docker and shadow as examples of what a child might inadvertently keep. Those memberships matter in practice: the docker group is generally treated as root-equivalent on a host, and the shadow group can expose password hashes.
Remediation steps
The report recommends the following actions:
- Upgrade to AnyIO 4.14.2 or later wherever affected versions are installed.
- Use
pip show anyioto inventory installations across Python environments. - Pin
anyio >= 4.14.2in requirements.txt, pyproject.toml or Pipfile so the patched version is enforced as a dependency. - Run automated vulnerability scanning to confirm the CVE is closed.
- Where an upgrade is not immediately possible, use Python's native asyncio or subprocess modules directly for code paths that depend on privilege dropping.
Teams that relied on extra_groups as a security control should also re-examine the actual group memberships of processes spawned by the affected releases, since the intended restriction was silently ignored rather than rejected.
Why it matters
Privilege dropping is a security boundary, and this bug shows how quietly such a boundary can fail. The vulnerable code accepts the arguments, launches the process and reports success — tests, code review and monitoring all see a healthy call, while the child quietly inherits elevated group access. The exposure window is narrow, limited to two point releases, but any deployment pinned to 4.14.0 or 4.14.1 that spawns subprocesses with reduced privileges is affected and should treat the upgrade as a priority. For library maintainers it is also a reminder that security-relevant arguments deserve verification of their effective outcome, not just their acceptance.
- #python
- #security
- #cve
- #anyio
- #privilege-escalation