Improper daemon-client authorization in NixOS Nix on unsandboxed macOS and FreeBSD

Nix before 2.35.3, when unsandboxed on macOS or FreeBSD, incorrectly allows connections made by build users from daemon clients.

• The normalized record marks Nix as affected from 0 through less than 2.28.8; from 2.29.0 through less than 2.30.6; from 2.31.0 through less than 2.31.6; from 2.32.0 through less than 2.34.9; and from 2.35.0 through less than 2.35.3.
• The NixOS advisory also states that older versions are affected to varying degrees. The 2.29.x, 2.32.x, and 2.33.x lines are no longer maintained by Nix and will not receive fixes.
• Confirmed fixed releases are 2.28.8, 2.30.6, 2.31.6, 2.34.9, and 2.35.3.
• The key platform condition for this issue is an unsandboxed Nix deployment on macOS or FreeBSD; exposure should not be generalized to every Nix deployment without verifying that condition.

Nix does not correctly reject connections originating from build users when the daemon runs unsandboxed on macOS or FreeBSD. The affected component is the client-to-nix-daemon connection authorization path; the advisory reference identifies LOCAL_PEERCRED, but the returned evidence does not identify the exact failing function or check. The attacker must be able to operate locally in the build-user context; the normalized record describes local reachability, no authentication or user interaction requirement, and low attack complexity. The advisory says this condition exacerbates the impact of an unprivileged repair exploit, but the available evidence does not establish a standalone path to arbitrary code execution or root privileges.

The issue is locally reachable and applies when Nix is unsandboxed on macOS or FreeBSD. The normalized record indicates that no prior privileges or user interaction are required and that exploitation has low complexity. The advisory states that the daemon failed to reject connections from build users, increasing the impact of an unprivileged repair issue. The record does not establish whether exploitation has occurred in the wild, and it identifies no public exploit.

The flaw weakens authorization at the boundary between a build user and the Nix daemon, potentially allowing a local peer to make a connection that the daemon should reject. The recorded outcome is integrity impact with a changed trust scope; the record does not indicate confidentiality or availability impact. The advisory states that the flaw can amplify the impact of an unprivileged repair exploit and may contribute to a privilege-escalation chain when issues are combined, but it does not show that this CVE alone grants root privileges. The practical organizational consequence depends on the coexistence of a multi-user daemon, build users, and untrusted derivations.

Nix environments that build untrusted code or derivations may allow a build user to reach daemon operations that should be restricted based on peer identity. The confirmed consequence is primarily an integrity risk across the trust boundary between the build user and the daemon; the record does not indicate a confidentiality or availability impact. The risk is most relevant to multi-user deployments on unsandboxed macOS or FreeBSD. The advisory links this flaw to increased impact from an unprivileged repair exploit, but it does not identify a specific breach, victim, or campaign.

1. Upgrade Nix to a confirmed fixed release: 2.28.8, 2.30.6, 2.31.6, 2.34.9, or 2.35.3, selecting the supported branch appropriate for the deployment.
2. For unsupported lines such as 2.29.x, 2.32.x, and 2.33.x, migrate to a supported branch containing a fix rather than waiting for a patch to the old line.
3. Prioritize unsandboxed macOS and FreeBSD systems, especially where build users can connect to the daemon or where untrusted derivations are built.
4. The available advisory does not document a separate confirmed workaround for this issue. If an upgrade cannot be completed immediately, restrict untrusted builds and reduce daemon exposure to build-user connections as precautionary measures, not as a replacement for patching.

1. Inventory operating systems, Nix versions, and daemon-backed deployments, especially multi-user installations.
2. Compare installed versions with the affected ranges in affected summary rather than assuming that any available update is sufficient.
3. Identify macOS and FreeBSD systems running Nix unsandboxed, and determine whether build users can interact with the daemon.
4. If the environment records peer credentials or process identities, review daemon connection telemetry for connections originating from build users. Treat this as a precautionary review, not as a confirmed IOC.
5. Do not treat the absence of suspicious connection records as proof of safety; determine exposure primarily from the installed version and deployment conditions.