CVE-2025-52992 is a vulnerability classified under CWE-732 (Incorrect Permission Assignment for Critical Resource) affecting the Nix family of package managers, including Nix, Lix, and Guix. These package managers are widely used for reproducible builds and functional package management in various Linux distributions, notably NixOS. The vulnerability arises because when a derivation build fails, the package managers do not correctly set file permissions on the build artifacts or store paths. This improper permission assignment can allow arbitrary processes outside the intended build sandbox to modify the contents of the store. The store is a critical component in these package managers, holding immutable build outputs and dependencies. By modifying store contents, an attacker could potentially inject malicious code or tamper with software artifacts, undermining the integrity of the software supply chain. The affected versions include Nix before 2.24.15, 2.26.4, 2.28.4, and 2.29.1; Lix before 2.91.2, 2.92.2, and 2.93.1; and Guix before 1.4.0-38.0e79d5b. The CVSS v3.1 base score is 3.2, indicating a low severity, with the vector AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N. This means the attack requires local access (local vector), high attack complexity, no privileges required, no user interaction, and impacts integrity with a scope change but no confidentiality or availability impact. No known exploits are currently reported in the wild. The vulnerability is significant in environments where these package managers are used for critical software deployment and development workflows, as it could allow unauthorized modification of build outputs, potentially leading to supply chain compromise or deployment of tampered software.

For European organizations, especially those using Nix, Lix, or Guix in their software development pipelines or production environments, this vulnerability poses a risk to the integrity of their software supply chain. Organizations relying on these package managers for reproducible builds or secure deployment could face unauthorized modification of build artifacts, leading to potential insertion of malicious code or corrupted software components. This could result in compromised applications, data breaches, or further lateral movement within internal networks. The impact is primarily on integrity, with no direct confidentiality or availability effects reported. However, the scope change indicates that the vulnerability could affect resources beyond the initial compromised build environment. European entities in sectors such as finance, critical infrastructure, research institutions, and technology companies that adopt NixOS or related package managers are particularly at risk. Given the local access requirement and high attack complexity, the threat is more relevant in environments where multiple users have local system access or where build environments are shared or exposed. The lack of known exploits reduces immediate risk but does not eliminate the threat, especially as attackers may develop exploits over time.

To mitigate this vulnerability, European organizations should promptly upgrade to the fixed versions of Nix, Lix, and Guix as specified: Nix versions 2.24.15, 2.26.4, 2.28.4, or 2.29.1 and later; Lix versions 2.91.2, 2.92.2, or 2.93.1 and later; and Guix version 1.4.0-38.0e79d5b or later. Until upgrades are applied, organizations should restrict local access to build environments and ensure that only trusted users have permissions to initiate builds or access store paths. Implement strict sandboxing and isolation of build processes to prevent unauthorized modification of store contents. Regularly audit file permissions on store directories and monitor for unexpected changes. Employ integrity verification mechanisms such as cryptographic hashes or signatures on build outputs to detect tampering. Additionally, consider using mandatory access controls (e.g., SELinux, AppArmor) to enforce strict policies around build and store directories. Educate developers and system administrators about the risk and ensure that build failure handling does not leave residual insecure permissions. Finally, maintain up-to-date monitoring and incident response capabilities to detect and respond to any suspicious activity related to package management and build systems.