Nx CVE-2026-104854

Exploitation requires (1) a Unix-like host (macOS/Linux - the advisory notes Windows named pipes are not filesystem objects and this does not apply), (2) a vulnerable Nx version (14.6.0 up to but not including 22.7.9, or 23.1.x before 23.1.2), (3) a running Nx daemon OR isolated plugin-worker process creating sockets in a shared temp location such as /tmp/.nx (default when owner-only 0700 directory/socket permissions are absent), and critically (4) a SECOND unprivileged local account on the same shared build server, developer host, or multi-user container controlled by the attacker. Key limiting factors: single-user machines with no other local account are NOT exposed; the attacker must already possess local access as a distinct user (PR:L) and be able to write a module file readable by the socket handler. Note the partial mitigation trap: disabling the daemon (NX_DAEMON=false) does NOT remove the still-vulnerable plugin-worker sockets, so only upgrading or enforcing owner-only socket/directory permissions fully closes the exposure.

This is a local privilege-escalation/code-execution flaw (CWE-269) in Nx, scored CVSS 4.0 8.5 by the GitHub-issued advisory (AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H). The vector is unambiguously local and requires an existing low-privileged account (PR:L), so despite the high score this is NOT a remotely exploitable, internet-facing issue - it is gated behind the attacker already having a foothold as a separate unprivileged user on the SAME host. No EPSS score, CISA KEV listing, or public POC is present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The real-world priority is therefore scenario-dependent: it is a genuine and serious risk on multi-tenant/shared build servers, CI runners, and multi-user containers (where lateral movement between user accounts is the goal), but the vendor explicitly notes single-user machines with no other local account are not exposed, which sharply narrows the realistic attack surface. Treat as high priority for shared/CI infrastructure and low priority for single-developer workstations. Note the daemon-disable mitigation is incomplete - plugin-worker sockets remain vulnerable - so configuration-based mitigation should not be relied upon in place of upgrading.

On a shared build server or multi-user CI container, a low-privileged attacker with their own local account discovers another user's running Nx daemon or plugin-worker Unix socket in a world-reachable temp directory (e.g. under /tmp/.nx). Because the transport performs no authentication, the attacker connects and sends a PROCESS_IN_BACKGROUND request pointing at a module file they control, causing its default export to be invoked and executing arbitrary code as the victim account running Nx. No public exploit was identified in the supplied data, but the attack is straightforward given a low-privilege foothold.