CVE-2026-104854 in Nrwl
Summary
by MITRE • 10/02/2026
Nx is a monorepo solution for TypeScript and polyglot codebases. From 14.6.0 until 22.7.9 and 23.1.2, Nx creates Unix domain sockets for its daemon and isolated plugin workers in shared temporary locations without owner-only directory and socket permissions. Another unprivileged local account on a shared build server, developer host, or multi-user container can discover and connect to a running socket because the transport performs no authentication and relies on filesystem containment. The daemon's PROCESS_IN_BACKGROUND request accepts a module path and invokes its default export, allowing a caller that controls a file to execute code as the account running Nx; other handlers can expose workspace file contents, project graphs, and task hashes. Disabling the daemon alone does not remove the vulnerable plugin-worker sockets, while single-user machines without another local account are not exposed. This issue is fixed in versions 22.7.9 and 23.1.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified within Nx, a popular monorepo management tool for TypeScript and polyglot codebases, stems from insecure handling of Unix domain sockets used for inter-process communication between the central daemon and isolated plugin workers. Specifically, in versions ranging from 14.6.0 through 22.7.9 and up to 23.1.2, these sockets are created in shared temporary directories without enforcing owner-only permissions on either the containing directory or the socket file itself. This configuration flaw means that any user account with access to the underlying operating system can list the contents of the temporary directory, identify the active Nx daemon socket, and establish a connection to it. The security model incorrectly relies solely on filesystem containment for isolation, assuming that because the sockets are in a temp folder, they remain private, which is an incorrect assumption in multi-user environments such as shared build servers, developer workstations with multiple local accounts, or containerized CI/CD pipelines where different processes may run under distinct user identities.
From a technical perspective, this misconfiguration allows unprivileged local users to interact directly with the Nx daemon without any form of authentication or authorization checks. The Unix domain socket transport layer does not validate the identity of the connecting process beyond standard OS-level file permissions, which are insufficiently restrictive in this context. Once connected, an attacker can exploit specific request handlers exposed by the daemon. Most critically, the PROCESS_IN_BACKGROUND handler accepts a module path and invokes its default export, effectively allowing arbitrary code execution under the security context of the user account running the Nx process. This capability transforms what might seem like a simple information disclosure issue into a severe remote or local code execution vulnerability depending on the environment's trust model. Additionally, other handlers can be abused to exfiltrate sensitive workspace data, including full project graphs, source file contents, and internal task hashes, which could aid in further reconnaissance or supply chain attacks against the development workflow.
The operational impact of this vulnerability is significant for teams utilizing shared infrastructure. In a multi-user environment, an attacker with low-level access can compromise the integrity of builds by injecting malicious code via the PROCESS_IN_BACKGROUND handler, potentially leading to credential theft, data exfiltration, or the introduction of backdoors into the software supply chain. Even in single-user environments where no other local accounts exist, the risk is mitigated but not entirely eliminated if the system is compromised through other means that allow file access. Notably, simply disabling the Nx daemon does not fully remediate the issue because isolated plugin-worker sockets may remain active and vulnerable until explicitly cleaned up or restarted with correct permissions. This persistence of vulnerability highlights a deeper architectural flaw in how temporary resources are managed during runtime operations.
To mitigate this risk, organizations must upgrade to patched versions 22.7.9 or 23.1.2 immediately, as these releases address the permissioning issues on Unix domain sockets and enforce stricter access controls. For environments that cannot be upgraded instantly, administrators should ensure that Nx is run in single-user contexts where possible, avoiding shared build servers with multiple untrusted users. Additionally, implementing strict filesystem permissions on temporary directories used by development tools can provide a layer of defense-in-depth. Security teams should also monitor for unusual process creation events or network connections to Unix sockets originating from unexpected user accounts as part of their endpoint detection and response strategies. This vulnerability aligns with CWE-732 improper permission assignment for critical resources and CWE-284 improper access control, while the exploitation technique relates to ATT&CK techniques involving local privilege escalation and command-line interface abuse through legitimate system utilities.