Nix and Lix patch daemon flaws that allow local root

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-nix can 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.