A critical privilege escalation vulnerability in the Nix package manager — tracked as CVE-2026-39860 (CVSS 9.0) — was disclosed on April 8, 2026. The flaw allows any unprivileged user who can submit builds to the Nix daemon to overwrite arbitrary files as root, achieving full system compromise on NixOS and multi-user Nix installations.
What Happened
The NixOS security team published advisory GHSA-g3g9-5vj6-r3gj detailing a sandbox escape in how the Nix daemon handles fixed-output derivation (FOD) output registration. The vulnerability is a regression introduced in the fix for CVE-2024-27297, an earlier sandbox escape patched in 2024.
The irony is not lost — a security fix for a sandbox escape inadvertently created a new sandbox escape with the same impact class.
Technical Details
During the build of a fixed-output derivation on Linux, the Nix daemon copies the build output from a temporary location inside the build chroot to the Nix store. The vulnerability exists because that temporary copy destination (.tmp) resides inside the chroot filesystem, which is writable by the sandboxed builder process.
The attack works as follows:
- An attacker crafts a malicious fixed-output derivation.
- During the build, the builder creates a symlink at the
.tmpcopy destination, pointing to an arbitrary path on the host filesystem (e.g.,/etc/shadow,/etc/sudoers, or any systemd unit file). - When the Nix daemon (running as root in the host mount namespace) performs the output registration copy, it follows the symlink and overwrites the target file with attacker-controlled content.
This is a classic TOCTOU (time-of-check-time-of-use) symlink race, except in this case there is no race — the daemon unconditionally follows the symlink, making exploitation deterministic.
Sandboxed macOS builds are not affected. The vulnerability is specific to the Linux sandbox implementation.
Impact
The impact is severe for any multi-user Nix installation:
- NixOS systems: The Nix daemon runs as root by default. All users in the
allowed-userslist (which defaults to all users) can submit builds. Any local user can escalate to root. - Multi-user Nix on other Linux distros: Same exposure. If you installed Nix with
--daemonmode, you are affected. - Single-user Nix installs: Not affected, since there is no privileged daemon involved.
- CI/CD pipelines using Nix: If your build infrastructure runs multi-user Nix and allows untrusted inputs to influence derivations (e.g., Hydra, Garnix, or custom CI), a malicious contributor could achieve host compromise.
The ability to write arbitrary files as root trivially leads to full system takeover — overwrite /etc/passwd, drop an SSH key into /root/.ssh/authorized_keys, or plant a malicious systemd service.
Affected Versions
All Nix versions with the original CVE-2024-27297 fix through to the latest releases prior to the patch are affected on Linux multi-user installations.
Patched Versions
The NixOS team released fixes across all supported branches:
- 2.34.5
- 2.33.4
- 2.32.7
- 2.31.4
- 2.30.4
- 2.29.3
- 2.28.6
What To Do Right Now
Update Nix immediately. Run
nix upgrade-nixor update your NixOS channel and rebuild. If you are pinning Nix versions, bump to one of the patched releases above.Audit your
allowed-userssetting. If you have not restrictedallowed-usersin/etc/nix/nix.conf, every user on the system can submit builds. Lock this down to only trusted users and groups.Check for signs of exploitation. Look for unexpected modifications to sensitive files (
/etc/shadow,/etc/sudoers,/etc/ssh/sshd_config, systemd unit directories). Compare against your configuration management baseline.Review CI/CD Nix configurations. If you run Hydra or any CI system that evaluates Nix expressions from external contributors, treat this as a critical infrastructure update. Untrusted PRs could contain malicious FODs.
Consider single-user mode for development. If you run Nix only for local development and don’t need multi-user isolation, single-user mode eliminates this attack surface entirely.