This post is a pre-disclosure announcement for upcoming security releases of Nix and Lix.
The Snyk Security Labs team has identified and reported the vulnerabilities that will be fixed by these releases.
Disclosure and Release Details
Release Date: June 24, 2025 at 14:00 UTC
Both Nix and Lix are affected
Branch releases that will receive the fixes:
Nix: 2.24, 2.26, 2.28 and 2.29
Lix: 2.91, 2.92 and 2.93
All systems building untrusted derivations are impacted. Both Linux and Darwin are affected, with Linux systems experiencing a greater impact due to the default-enabled sandbox on them.
Expect full disclosure of the issues after the publication of the patches and releases.
Are there any cautionary measures that should be taken until the releases hit masadoption, which due to the way how nixpkgs work, will very likely not happen before June 27th!
Is the fix already in the nightly builds, or is it held back in secret until release day?
No we do not have the possibility to prefill the caches but it does not imply large rebuilds so the changes will land in the release branches relatively quickly and applying the patches/pulling the new versions with an override in your config is also quite doable.
CVSS scores are complex beast and not really meaningful without adjusting to a specific context/threat model. This is not really something that can be provided in a pre-disclosure announcement.
Most people donât build untrusted derivations in the first place, so the impact on users who donât run publiclyâexposed CI/build infrastructure is probably minimal.
(Well, okay: most people donât ensure that derivations are trustworthy before building them. But they also tend to use the outputs of those derivations in ways that would allow them to be exploited regardless of the Nix sandbox â the Nix sandbox only protects you if you never run code from derivation outputs outside of a sandbox anyway. Maybe just avoid running nixpkgs-review on PRs?)
For your information, I have edited the first post to mention that the Guix project is also part of this coordinated disclosure, as they now have published their pre-announcement
To clarify for those not familiar with the architecture that many projects use to try to prevent this type of bug from mattering at all by keeping Nix out of the trusted computing base: NixOS/nixpkgs has two CI systems, Hydra, which is trusted and only builds master or branches written by trusted people, and OfBorg, which cannot write to cache.nixos.org and which builds untrusted PRs.
Lix, similarly, only has untrusted CI: our buildkite builds proposed changes and main, but does not write to any publicly accessible cache. Lix binary releases are built on trusted dev machines at the moment and are, to the best of my knowledge, bit-reproducible on Linux.
This is relating to the recommendations of Lixâs multi-user security model docs which I rewrote a few months back to clarify what we consider the intended security model: Multi-User Mode - Lix Reference Manual
I use NixOS on a personal computer for stuff like replying to e-mails, browsing the web, playing games, and pushing code to remote Git repositories. Iâve modified my configuration.nix, but I donât know what an âuntrusted derivationâ is. Will the June 24 disclosure explain, in terms that I can understand, what I need to do to keep my system secure? If not, where can I find out?
@fareycircles Assume the worst - that itâs possible for stuff inside build sandbox to gain full root on host (just my speculation)
Do you expect any package/derivation/flake input that youâre using to be malicious and attempt to abuse such thing? If not then youâre fine, but if you want to be extra cautious then donât run flake update until the patch is in nixpkgs on the branch that youâre using. (and maybe bump only nixpkgs first, switch to newer nix/lix, then update the rest of stuff)
Another case is when you have for example a shared server where various people which you donât control are in allowed-users and can build various stuff on their own - consider them untrusted.
Thanks for the advice! Let me repeat what Iâve understood of it to see if Iâm reading it correctly.
When I run nixos-rebuild, my system runs code from various sources, which I shouldnât entirely trust. That code runs inside a âbuild sandboxâ which is supposed to restrict its access to my system, reducing its ability to wreak havoc.
This vulnerability may weaken the walls of the build sandbox, allowing the code run by nixos-rebuild to access parts of the system that it shouldnât be allowed to touch.
Itâs risky to call nixos-rebuild before the branch of nixpkgs that Iâm using is patched, because the code it runs could exploit this vulnerability.
Itâs probably still safe to boot and run the current build of my system.
yes, but since no one except from few trusted people knows what this exactly is, someone exploiting this in the wild before reveal is very unlikely, so it should be safe to update inputs and rebuild right now anyway.
youâre also fine to nixos-rebuild with what you currently have since everything is hashed/pinned to commits and wonât somehow magically turn malicious
basically once the vuln is disclosed and patch is merged/out in channels, update only nixpkgs first. Before disclosure you can do pretty much whatever you want
When I run 
Itâs risky to call 
Itâs probably still safe to boot and run the current build of my system.