Nix CVE-2026-110450

Requires local access to a Nix (before 2.35.3) or Lix (before 2.95.4) installation, and specifically a multi-user daemon deployment where unprivileged users submit operations to a privileged nix-daemon. Exploitation hinges on a repair/verify operation that destroys a store path and replaces it before content verification, so the attacker must act within that destroy-then-replace window to substitute malicious content. Limiting factors: no remote network reachability (AV:L), dependence on the privileged-daemon multi-user configuration, and the timing-sensitive ordering window that an attacker must win; single-user installs are far less exposed.

The input CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L, base 8.0) describes a local, no-privilege-required flaw with high confidentiality and integrity impact - consistent with a local privilege-escalation primitive in a multi-user Nix/Lix daemon setup. CWE-696 (Incorrect Behavior Order) matches the description: the repair operation destroys and then replaces a store path before content verification, an ordering/TOCTOU weakness. No EPSS score, no CISA KEV listing, and no POC were provided, so exploitation status is 'no public exploit identified at time of analysis' - this is a patch-and-advisory-driven disclosure rather than an observed-in-the-wild threat. One point of tension: the input rates AC:L, but an ordering flaw that requires substituting a store path during the narrow destroy-then-replace window typically demands a timing race, which argues for higher attack complexity; I have assessed AC:H independently below. Net: a genuine local EoP worth prioritizing on shared/multi-user Nix build hosts, but not an internet-facing mass-exploitation priority given the local attack vector and absence of exploitation signals.

On a multi-user Nix or Lix installation, an unprivileged local user triggers (or waits for) a store-path repair operation and races the daemon to substitute malicious content into the store path after it is destroyed but before content verification completes. The planted path is then trusted and used with daemon/root privileges, yielding privilege escalation. No public exploit code was identified at time of analysis; exploitation is local and timing-dependent.