uutils coreutils CVE-2026-35367

Exploitation requires all of the following concrete conditions: (1) uutils coreutils is installed and nohup utility is invoked to create nohup.out (not GNU coreutils, which is not vulnerable); (2) the process running nohup has executed it in a directory where file creation is subject to standard umask permissions (typical case-not restricted by mandatory access controls like SELinux or AppArmor policies that enforce stricter defaults); (3) the attacker is a local user with shell access or file-read privileges on the system where nohup.out resides (not network-accessible); (4) the nohup.out file contains output worth reading (sensitive data, credentials, paths, configurations-not guaranteed but common in deployment/logging contexts); (5) the file persists on disk and has not been manually chmod'd to 0600 by the user (nohup.out is typically long-lived, making this likely). If nohup.out is created in a directory with restricted parent permissions, or if the system enforces strict default umask (0077) globally, exploitation may not yield sensitive information. The vulnerability is NOT present if GNU coreutils is the active nohup implementation.

This vulnerability presents a low-to-moderate real-world risk despite its low CVSS score of 3.3. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) correctly reflects that exploitation requires local access and authenticated user privileges, with no impact on integrity or availability-purely confidentiality compromise. SSVC data confirms exploitation is possible but not automatable (POC exists, automatable=no), and technical impact is partial (information disclosure only). The key limiting factor is that this only affects systems where: (1) uutils coreutils is the active nohup implementation (not standard GNU coreutils), (2) sensitive data is being captured in nohup.out output, and (3) a local attacker has shell access or user-level privileges. This is not a network-exploitable issue and requires an attacker already on the system. However, in shared hosting environments, containers with multiple users, or development systems where developers run background jobs with nohup, this creates a genuine privacy leak. The discrepancy with GNU coreutils' behavior is notable-defenders relying on uutils for GNU compatibility may have false assumptions about permission security. Active exploitation likelihood is low due to narrow deployment scope (uutils is less common than GNU coreutils), but the technical vulnerability is straightforward and POC-verified.

A developer on a shared multi-user system uses uutils coreutils' nohup to run a background task: nohup ./deploy.sh > nohup.out 2>&1 &. The deploy script outputs database credentials and API keys to stdout for logging purposes. A second user on the system (different account, same machine) reads nohup.out via cat nohup.out and gains access to the credentials because the file is world-readable (0644). The attacker now has credentials to database and API services.