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.
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.
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.
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.
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.
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.
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.
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.
The -small branches are useful for this, as you get at least some guarantees, and basic package builds, though for at least desktop systems that is still not ideal:
… but tbh just wait if you’re on a desktop (and don’t evaluate any nix code until you can eval a nixpkgs with this commit), or outright switch to lix.
I am curious why there was an embargo when a fix (migrate to Lix ) was immediately available. After all, the issue was deemed critical enough for the infra team to switch over, but seemingly not critical enough to get a fix into the hands of everyone else quickly?
I think a post mortem from the security team with a timeline would be appropriate here.
I believe that the it wasn’t known that Lix’s fix for the 2024 bug was also secure against this new bug until this new bug was found in cppnix.
It would have taken the same amount of time to propagate a change through all the channels as the cppnix patch did. Without the guarantee that everything would work due to their incompatibilities.
Oh, I missed that phrase, sorry. That’s probably the regular embarggo that’s just part of the deal between secret disclosure and actually having a fix.