Pre-disclosure announcement: Security Advisory for Nix and Lix on June 24, 2025

Announcements Security
1

Hello everyone,

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.

This is a coordinated disclosure between the Nix, Lix and Guix projects. The Guix project also made an announcement: Upcoming security disclosures on June 24, 2025 [guix-devel mail archive].

52 Likes
2

I appreciate this kind of upfront announcement ! Great job, very professional.

11 Likes
6

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?

2 Likes
7

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.

8

What is the CVE score?

1 Like
9

You mean CVSS score?
The CVE number is an identifier.

1 Like
10

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.

5 Likes
11

Sad that you didn’t answer the “is there anything we should do now” part of the question…

12

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?)

4 Likes
14

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 :slight_smile:

6 Likes
15

Thanks! The post became longer as I was reading it :stuck_out_tongue:

1 Like
16

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

11 Likes