The Nix and Lix projects jointly disclosed security flaws on October 13, 2026 that can be chained into root access on machines running their package-building daemons. Fixed releases came out the same day. Any multi-user Nix or Lix setup where untrusted users can reach the daemon should upgrade now.
Nix is a package manager and build system that underpins the NixOS Linux distribution. Lix is a separate implementation of Nix. Both run a background service, the daemon, that builds software on behalf of local users.
The flaws
The joint advisory on NixOS Discourse lists several issues. The most serious lets a local user corrupt files that later run as root.
| Issue | Who is affected | Severity |
|---|---|---|
| Unprivileged "repair" requests can replace store files before they are checked | Multi-user installs on Linux and macOS | High, 8.4 out of 10 (Nix advisory) |
Integer overflow in builtins.genList causes a heap memory write |
Systems that evaluate untrusted Nix code | Moderate |
| macOS sandbox escape when a build's sandbox profile grows past a size limit | macOS with sandbox = true or relaxed
|
Moderate |
| Multi-user installer leaves store files owned by the installing user | Fresh installs through the scripted installer; NixOS is not affected | Moderate, 5.6 |
| Daemon accepts connections from build users | macOS and FreeBSD; Linux is not affected | Low, 3.8 |
The Nix side has published five GitHub advisories. None has a CVE number yet.
How the root escalation works
The main bug sits in how the daemon adds files to the Nix store, the directory where all built software lives. According to the Nix advisory GHSA-jwvx-xq5j-gc56, the daemon unpacked an uploaded archive straight into its final store path. It checked the archive's hash only afterward.
Vulnerable versions also let untrusted users request a "repair", which replaces an existing store path. If the hash check failed, the malicious files stayed on disk. When the daemon runs as root, the advisory says, any user listed in allowed-users could execute code as root.
The flaw dates back to Nix 2.1, which added streaming uploads. The fix bars untrusted users from repair mode. It also unpacks uploads into a private temporary folder and moves them into place only after the hash checks out.
The advisory credits Guthrie McAfee Armstrong and a researcher known as joaoviictorti for finding it.
Which versions to install
| Project | Fixed versions |
|---|---|
| Nix | 2.35.3, 2.34.9, 2.31.6, 2.30.6, 2.28.8 |
| Lix | 2.95.4, 2.94.3 |
The advisory says unsupported Nix branches 2.29, 2.32 and 2.33 should be presumed vulnerable. Lix 2.93 and older are affected but no longer maintained. Updates are in progress for the NixOS unstable and 26.05 channels.
The Guix package manager is not affected.
A timeline months in the making
The Lix team's write-up shows how long coordination took. The overflow bug was disclosed to the team on July 29, and fixes were ready on August 29. The macOS privilege escalation chain arrived on September 12, and the sandbox escape on October 9.
The Lix post stresses that its daemon is not a security boundary. It advises build farms to run the daemon as an unprivileged user where possible.
Tech AI Wire covered a separate supply-chain concern last month, a tampered strip binary that could backdoor NixOS.
What this means for developers
- Upgrade every multi-user install. Any machine where more than one person or service talks to the Nix daemon is exposed. Single-user setups face less risk, but should still update.
-
Use the right Lix upgrade path. The advisory warns that plain
nix upgrade-nixcan uninstall Lix 2.95.x before installing the new version. Use the Lix 2.95.4 upgrade script instead. - Check store ownership after scripted installs. If Nix was installed with the multi-user script, the advisory gives commands to make every store path owned by root again.
-
Audit
allowed-users. Until you upgrade, everyone on that list can effectively become root. Trim it to the accounts that need to build. - Treat untrusted Nix code as untrusted. CI systems that evaluate pull requests from strangers could hit the overflow bug. Run those evaluations in isolated machines.
This article was first published on Tech AI Wire.
Also available in
Deutsch · 日本語 · Français · Español · Português
Top comments (0)