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

Announcements Security
1

Summary

Nix daemon is vulnerable to arbitrary file overwrites as the daemon user (root on NixOS and in multi-user installations). The issue is identified as GHSA-g3g9-5vj6-r3gj and CVE-2026-39860.
All users allowed to submit builds to the Nix daemon (allowed-users, everyone by default) can achieve arbitrary file writes as root and subsequent privilege escalation.

Am I affected?

All Nix versions since 2.21 and patch releases >=2.18.2,>=2.19.4,>=2.20.5 prior to 2.34.5, 2.33.4, 2.32.7, 2.31.4, 2.30.4, 2.29.3, 2.28.6 are vulnerable. This affects sandboxed Linux configurations, sandboxed macOS configurations are unaffected. All default configurations of NixOS and systems building untrusted derivations are impacted.

Lix users are not affected.

Patches

  • Fixed versions: 2.34.5, 2.33.4, 2.32.7, 2.31.4, 2.30.4, 2.29.3, 2.28.6.

Patched nix versions of are being updated in nixpkgs:

This vulnerability has been introduced as a part of prior fixes for CVE-2024-27297.

Patches for versions 2.31..2.34 include additional mitigations to prevent cooperaing fixed-output derivations from communication and passing file descriptors between distinct sandboxes.

Acknowledgement

We’d like to thank @edef for disclosing this vulnerability to the Nix team, @edolstra for coordinating the fixes with Determinate Nix, @hexa and the infrastructure team for temporarily switching hydra.nixos.org builders to Lix for the duration of the embargo.

31 Likes
3

How come this issue doesn’t affect Lix?

1 Like
4

I would assume because this commit is not in the Lix repo.

oops this was supposed ot be a direct reply to @nyanbinary

3 Likes
5

Lix took a different path in remediating CVE-2024-27297. This issue is specific to how CppNix implemented their remediation.

1 Like
6

I made an announcement over in the Discord community and something we’re getting a LOT is:

  • “Does this affect me?”
  • “Does this affect my branch?”
  • “Is the fix in branch XYZ yet?”

Using this as a learning experience, I think it would be a swell idea to make a simple webserver for seeing if a CVE affects you.
I think it could be as simple as URL parameter(s) where OP or the one who posts the link can specify “positive” commit hashes, and “negative” commit hashes.
When the webserver receives a query, it checks each branch for the following states

  • Not Affected - The branch has none of the positive commits.
  • Still Affected - The branch has at least one positive commit and zero negative hashes.
  • Remedied - The branch has at least one negative hash.

If the idea is sound I wouldn’t mind developing this myself for whatever author for future instances of these posts.

2 Likes
7

Different as in move vs rename

8

Yes

You are describing more or less the PR tracker I linked above just with different text output.

9

More or less, yeah fair. Granted there is two big differences. My idea also supports showing if the CVE was never applied to a specific branch in the first place, meanwhile with the PR tracker you would also have to check the PR which created the CVE. Also, my idea is both commit based and can have multiple commits, meaning if there are two different PRs to say merge the fix into two different branches, my idea would handle that, also if there are two different fix commits (e.g. if the relevant code has been updated since the CVE introduction meaning in order to apply the fix to an old branch some tweaks are needed), then my idea would handle it.
Possibly overcomplication. I’m still open to hearing thoughts.

10

An update bc I happened to revisit this in my mind.
It occured to me the link provided doesn’t show like, the majority of branches soooooo…
If I post this link for people then it will do nothing to the onslaught of “Is branch XYZ safe yet?”
Part of my idea is that it would show like all the branches (At least all the ones targeted towards consumers).
Frankly even I wouldn’t know if I hadn’t used the repl to check the version of Nix on various branches, so I can see how people are confused trying to figure out when a fixed version is available on a given branch.

11

Please note that you email everyone who subscribes to this category for urgent security notifications whenever you reply here. Consider discussing tangential matters in another thread.

16 Likes
12

Just as a note, if your flake or channel uses nixos-25.11 or even nixos-unstable at the time of writing the patches have not been ported to these branches/streams.

Instead, for 25.11 use release-25.11.

nix-shell -p nix -I nixpkgs=channel:nixos-25.11 --run "nix --version"   

nix (Nix) 2.31.3                                                          
 > nix-shell -p nix -I nixpkgs=channel:nixos-unstable --run "nix --version"

nix (Nix) 2.31.3+1

Update your system configuration flake to point to the correct ref that includes the patch for nixpkgs:

nixpkgs.url = "github:NixOS/nixpkgs/release-25.11";
1 Like
13

This is bad advice for the vast majority of users. release-XX.YY is not yet built by hydra. It is to nixos-XX.YY as master is to nixos-unstable. Changing your flake to follow it would mean you’d be permanently stuck locally compiling all kinds of stuff. Technically you can get the fix faster this way if you really don’t mind who-knows-how-much local compiling, but it’s unlikely to be worth it.

And whatever you do, don’t leave your config pointing to such a branch.

2 Likes