CVE-2026-110450 in Lix
Summary
by MITRE • 10/14/2026
Nix before 2.35.3 and Lix before 2.95.4 allow privilege escalation via a repair operation because it could destroy and then replace a store path before content verification.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in Nix versions prior to 2.35.3 and its fork, Lix, prior to version 2.95.4, represents a critical flaw within the package manager's repair mechanism that facilitates privilege escalation through improper handling of store paths during content verification processes. This issue stems from a race condition or logic error inherent in how the system manages atomicity when repairing corrupted or missing files within its immutable binary cache, known as the Nix Store. The core technical failure lies in the sequence of operations executed by the repair routine, which prioritizes availability and structural integrity over cryptographic verification at specific stages of file replacement.
When a user initiates a repair operation on a derivation that has suffered corruption or missing components, the system attempts to restore the expected state by downloading or copying fresh copies of the required files from configured nar sources. In vulnerable versions, the implementation allows for the destruction of existing store paths followed immediately by their replacement with new content before the cryptographic hash of the newly written data is fully verified against the expected value stored in the derivation metadata. This temporal gap creates a window where an attacker who has write access to any source repository or network path configured as a nar source can inject malicious payloads into these files. Because the system proceeds to link and activate these unverified paths, it effectively trusts potentially compromised content that matches no valid hash but is accepted due to the flawed repair logic.
The operational impact of this vulnerability is severe, particularly in environments where Nix or Lix are used with elevated privileges for building software packages or managing system configurations. An attacker capable of influencing the source repositories can achieve arbitrary code execution as the user initiating the build or repair process. If these operations are performed by root or a service account with broad permissions, the resulting compromise extends to full control over the host system. This is not merely an information disclosure issue but a direct path to privilege escalation and remote code execution, undermining the fundamental security guarantees of reproducibility and integrity that Nix aims to provide through its content-addressed store model.
This flaw aligns with CWE-367, Time-of-check to time-of-use (TOCTOU) race conditions, as it involves a discrepancy between when a check is performed and when an action based on that check occurs, although in this specific case, the verification step itself is bypassed or delayed incorrectly. Furthermore, from a threat modeling perspective consistent with MITRE ATT&CK techniques, this vulnerability supports T1059 Command and Scripting Interpreter for initial access if combined with other vectors, but more critically it facilitates T1068 Exploitation for Privilege Escalation by allowing an unprivileged user to manipulate system-level files during a repair cycle. The attack vector is primarily local or network-based depending on the configuration of trusted sources, making remote exploitation possible in setups that pull from untrusted or compromised mirrors.
Mitigation strategies require immediate upgrading to Nix version 2.35.3 or later and Lix version 2.95.4 or higher, where the repair logic has been corrected to ensure strict atomicity and verification before any store path is replaced. Administrators should also audit their configuration files for trusted users and sources, ensuring that only verified repositories are included in the nar source list. Implementing additional layers of integrity checking at the operating system level, such as using immutable file attributes on critical parts of the Nix Store where feasible, can provide defense-in-depth against similar future flaws. Regular auditing of build logs and verification of cryptographic hashes for all derived artifacts remains a best practice to detect any anomalies that might indicate exploitation attempts or residual corruption in vulnerable environments.