Sandbox symlink following enables arbitrary file overwrite and root escalation in NixOS nix

Nix is a package manager for Linux and other Unix systems. A bug in the fix for CVE-2024-27297 allowed for arbitrary overwrites of files writable by the Nix process orchestrating the builds (typically the Nix daemon running as root in multi-user installations) by following symlinks during fixed-output derivation output registration. This affects sandboxed Linux builds - sandboxed macOS builds are unaffected. The location of the temporary output used for the output copy was located inside the build chroot. A symlink, pointing to an arbitrary location in the filesystem, could be created by the derivation builder at that path. During output registration, the Nix process (running in the host mount namespace) would follow that symlink and overwrite the destination with the derivation's output contents. In multi-user installations, this allows all users able to submit builds to the Nix daemon (allowed-users - defaulting to all users) to gain root privileges by modifying sensitive files. This vulnerability is fixed in 2.34.5, 2.33.4, 2.32.7, 2.31.4, 2.30.4, 2.29.3, and 2.28.6.

NixOS nix is affected when performing sandboxed Linux builds in the following ranges:

• >= 2.18.2, <= 2.18.9.
• >= 2.19.4, <= 2.19.7.
• >= 2.20.5, <= 2.20.9.
• >= 2.21, < 2.28.6.
• >= 2.29.0, < 2.29.3.
• >= 2.30.0, < 2.30.4.
• >= 2.31.0, < 2.31.4.
• >= 2.32.0, < 2.32.7.
• >= 2.33.0, < 2.33.4.
• >= 2.34.0, < 2.34.5.

The corresponding fixed releases are identified as 2.28.6, 2.29.3, 2.30.4, 2.31.4, 2.32.7, 2.33.4, and 2.34.5. The advisory identifies sandboxed macOS builds as unaffected. The status of branches or versions outside these ranges is not established by this record alone.

NixOS nix has a CWE-61 flaw in fixed-output derivation output registration when builds run in the Linux sandbox. The temporary output location used for the copy is inside the build chroot, where the derivation builder can create a symlink pointing to an arbitrary filesystem location. During output registration, the Nix process running in the host mount namespace follows that symlink and overwrites the target with the derivation output. In multi-user installations, this process is typically the root-running Nix daemon, so users permitted to submit builds can affect files writable by the daemon. Public detail does not identify specific filesystem targets or implementation function names beyond the documented symlink, temporary output, and output-registration path.

The documented reachability is local and requires no additional user interaction after a relevant build is submitted. The vendor specifically identifies users who can submit builds to the Nix daemon as exposed, with allowed-users defaulting to all users. The normalized record contains different privilege assessments: the CNA vector records no privileges required, while the NVD vector records low privileges required; operationally, authorization to submit a build is the material precondition. Complexity is recorded as low, and no remote network path is described. The record marks public_exploit as false and does not mark the issue as known exploited, but those database states do not prove that exploitation is impossible or has never occurred.

The flaw lets an attacker control a symlink in the temporary output path and redirect the Nix copy operation to another filesystem location. The direct result is arbitrary overwriting of files writable by the build-orchestrating process. When that process is a root-running Nix daemon, the privilege boundary changes and a build-submitting user may obtain root privileges by modifying sensitive files. Confidentiality impact may follow because root access can expand access after files or configuration are modified, but the documented primitive is file overwrite rather than file disclosure. The issue is identified only for sandboxed Linux builds; the advisory states that sandboxed macOS builds are unaffected.

• System integrity: An attacker can cause the Nix process to overwrite files that the process is permitted to write, including sensitive files when the deployment exposes them.
• Privilege boundary: In multi-user installations, a root-running Nix daemon can turn build-submission access into the ability to modify resources outside the submitting user's normal scope.
• Data and configuration: Changes to configuration, credential, or system files could weaken security controls or cause unexpected application behavior; the record does not identify a specific target file.
• Operational limits: The documented primitive is arbitrary file overwrite. The record does not describe a specific outage scenario, so a confirmed availability impact should not be inferred.

1. Upgrade within the affected branch: use 2.28.6 for the 2.28 branch, 2.29.3 for the 2.29 branch, 2.30.4 for the 2.30 branch, 2.31.4 for the 2.31 branch, 2.32.7 for the 2.32 branch, 2.33.4 for the 2.33 branch, or 2.34.5 for the 2.34 branch. Do not infer the status of parallel branches or other versions merely because they have a higher version number.
2. Reduce exposure before upgrading: do not allow untrusted builds to be submitted to the Nix daemon through allowed-users, or make /nix/var/nix/daemon-socket inaccessible to untrusted users.
3. Check both daemon hosts and build workers to ensure the executing Nix binary is a fixed release, then restart the service or worker according to the deployment procedure.
4. Patches for the 2.31, 2.32, 2.33, and 2.34 branches also add hardening against communication and file descriptor smuggling between cooperating fixed-output derivations through abstract Unix sockets. This hardening is effective on kernels >= 6.12 with the Landlock LSM enabled; it is skipped on older kernels and does not prevent communication between fixed-output derivations and processes outside the Nix sandbox.
5. After remediation, review build-submission permissions, daemon-socket access, and sensitive files writable by the daemon. If unauthorized overwrites are suspected, investigate before simply restoring files or deleting build artifacts.

1. Inventory Nix versions on build hosts and on hosts running nix-daemon, then compare them with the affected branches.
2. Identify deployments using sandboxed Linux builds, fixed-output derivations, and multi-user installations; the advisory identifies sandboxed macOS builds as unaffected by this issue.
3. Review allowed-users and access permissions for /nix/var/nix/daemon-socket, especially on systems where untrusted users can submit builds.
4. Correlate build-submission records with unexpected changes to files writable by the daemon. This is a precautionary investigative check, not a vendor-published IOC.
5. If sensitive files were unexpectedly modified, correlate their modification times with fixed-output derivation builds and preserve evidence before upgrading or restoring files.