CVE-2022-42919 is a Linux-specific local privilege escalation vulnerability in Python's multiprocessing module, where the forkserver start method uses an abstract namespace socket that any local user can connect to and feed a malicious pickle for arbitrary code execution. Because unpickling can run arbitrary code, an attacker with a local account can escalate to the privileges of whatever user is running a forkserver process. It affects CPython 3.9.x before 3.9.16 and 3.10.x before 3.10.9.
This is not a remote code execution bug and it is not the default configuration, which is why it flew under many teams' radar. But on multi-user Linux hosts and shared build agents, it is exactly the kind of finding that turns a low-privilege foothold into a full compromise.
What the vulnerability is
Python's multiprocessing module supports three start methods for spawning worker processes: fork, spawn, and forkserver. The forkserver method launches a small server process once, then forks new workers from it on demand. Communication between the parent and the forkserver happens over a Unix domain socket.
On Linux, that socket was created in the abstract namespace. Abstract namespace sockets are identified by a name that lives in a kernel-managed namespace rather than on the filesystem, and critically they carry no filesystem permissions. Any process in the same network namespace can connect to one if it knows or guesses the name. The forkserver then reads a pickled payload from the connection and deserializes it.
Python's pickle format is not a safe data format. Deserializing an attacker-controlled pickle is equivalent to executing attacker-controlled code. Put those two facts together and you have the vulnerability: a local user connects to another user's forkserver socket, sends a crafted pickle, and the forkserver executes it as the higher-privileged user.
Why abstract sockets were the wrong choice
Filesystem-backed Unix sockets inherit directory and file permissions, so you can restrict who connects by placing the socket in a directory only the owning user can read. Abstract namespace sockets skip the filesystem entirely, which makes them convenient (no cleanup, no stale socket files) but removes that access-control layer. The name is the only thing standing between the socket and any local process, and names are not secrets.
The upstream fix, tracked in CPython issue 97514, moved the forkserver socket back to a filesystem path with restrictive permissions instead of the abstract namespace.
Affected versions
Verified against the NVD record and Red Hat's advisory:
Affected: CPython 3.9.0 – 3.9.15
CPython 3.10.0 – 3.10.8
Fixed in: 3.9.16
3.10.9
(and 3.11.1 / 3.7.x, 3.8.x backports per distro)
Platform: Linux only (abstract sockets are a Linux feature)
Vector: Local, requires the forkserver start method
The forkserver start method is not the default on any platform, so a large fraction of Python deployments are not exposed. You are only affected if your application (or a library it uses) explicitly calls multiprocessing.set_start_method("forkserver") or get_context("forkserver") and runs on Linux.
How to find out if you are exposed
Check three things. First, your Python version: anything at or above 3.9.16 / 3.10.9 already has the fix. Second, whether any code sets the forkserver start method. A quick grep across your codebase and vendored dependencies:
grep -rnE "forkserver|set_start_method|get_context" --include='*.py' .
Third, the runtime environment. This only matters on multi-user or shared hosts. A single-tenant container running one workload as one user has no other local user to launch the attack, which lowers the practical risk considerably even on a vulnerable interpreter.
Transitive exposure is the harder case: a dependency might select forkserver internally. An SCA tool can flag the vulnerable interpreter and libraries that carry the affected code so you are not grepping every third-party package by hand.
Remediation
The clean fix is to upgrade the interpreter. Move to CPython 3.9.16, 3.10.9, or any later release, or take your distribution's patched package, which several vendors backported to 3.7 and 3.8 builds.
If you cannot upgrade immediately, there are two mitigations. You can avoid the forkserver start method entirely and use spawn, which does not rely on the abstract socket path in the same way. Or you can disable abstract socket support so multiprocessing falls back to filesystem sockets:
import multiprocessing.util
multiprocessing.util.abstract_sockets_supported = False
Set that before any forkserver process starts. Treat both as stopgaps; the version upgrade is the real fix.
The broader lesson: pickle plus any channel is dangerous
CVE-2022-42919 is a specific socket-permissions bug, but the underlying pattern recurs across Python projects: an unauthenticated or weakly authenticated channel that carries pickled data. Redis caches storing pickles, message queues shuttling pickled tasks, and cache files written world-readable all reproduce the same primitive. If you audit your own code for one thing after reading this, make it "where do we unpickle data that crossed a trust boundary." For a structured approach to threat-modeling that kind of finding, our academy covers deserialization risk in depth.
FAQ
Is CVE-2022-42919 remotely exploitable?
No. It requires a local account on the same Linux host as the vulnerable forkserver process. It is a privilege escalation bug, not remote code execution.
Am I affected if I use the default multiprocessing settings?
Almost certainly not. The default start method is fork on Linux, not forkserver. You are only exposed if your code or a dependency explicitly selects the forkserver method.
What versions of Python fix it?
CPython 3.9.16 and 3.10.9 and later. Many Linux distributions also backported the fix to their 3.7 and 3.8 packages, so check your vendor's advisory if you run an older series.
Does switching to spawn instead of forkserver help?
Yes, as a mitigation. The spawn start method does not use the abstract-namespace socket that the vulnerability abuses. Upgrading the interpreter remains the recommended fix.