Nix security advisory: Privilege escalation via symlink following during FOD output registration

April 7, 2026
aisecuritylawopen-source
A close-up of a registration desk sign on a dark background.
Photo by RDNE Stock project on Pexels

Summary

It has been reported that the Nix daemon contains a serious vulnerability (GHSA-g3g9-5vj6-r3gj, tracked as CVE-2026-39860) that can allow arbitrary file overwrites by the daemon user — root on NixOS and on multi-user installations. In short: any account allowed to submit builds to the Nix daemon (the default is everyone) can potentially write files as root and escalate privileges. Ouch. That’s exactly the worst-case scenario for systems that accept untrusted derivations.

Scope and cause

The problem affects Nix versions back to 2.21 and many patch releases (see advisory for the exact cutoff list); sandboxed Linux configurations are vulnerable while sandboxed macOS configurations are not. Lix users reportedly are not affected. The bug was introduced during earlier fixes for CVE-2024-27297 and involves symlink-following during fixed‑output-derivation (FOD) output registration, which lets cooperating derivations communicate and pass file descriptors between otherwise isolated sandboxes.

Patches and response

Fixed releases have been published: 2.34.5, 2.33.4, 2.32.7, 2.31.4, 2.30.4, 2.29.3 and 2.28.6. Patched nix packages are being landed in nixpkgs (unstable: #507699, #507730; 25.11: #507681). The fixes include extra mitigations to stop cooperating FODs from talking to one another and from passing file descriptors across sandboxes. The Nix project acknowledged @edef for the disclosure and noted coordination with maintainers; hydra.nixos.org builders were temporarily switched to Lix during the embargo.

What to do

If you run Nix in multi-user mode or operate default NixOS installs, update to one of the fixed releases immediately and pull the patched nixpkgs. If you can’t upgrade right away, tighten allowed-users and avoid building untrusted derivations until you can. Want peace of mind? Treat any service that runs builds submitted by untrusted users as untrusted—because, here, the default settings were the problem.

Sources: discourse.nixos.org, Lobsters