CVE-2026-35367: 
Rust vulnerability analysis and mitigation

CVE-2026-35367 is an incorrect permission assignment vulnerability in the nohup utility of uutils coreutils (the Rust-based reimplementation of GNU coreutils). When nohup creates its default output file nohup.out, it does not specify explicit restricted permissions, causing the file to inherit umask-based permissions — typically resulting in world-readable permissions (0644) rather than the owner-only (0600) permissions enforced by GNU coreutils. This affects uutils coreutils versions up to and including 0.8.0 on multi-user Linux systems. The vulnerability was reported on January 3, 2026, and publicly disclosed on April 22, 2026, with a CVSS v3.1 base score of 3.3 (Low) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-732 (Incorrect Permission Assignment for Critical Resource). The uutils nohup implementation opens nohup.out using default file creation flags without explicitly setting restrictive permissions (e.g., O_CREAT with mode 0600), so the resulting file permissions are determined solely by the process's umask. With a typical umask of 022, the file is created as 0644, making it readable by all users on the system. An authenticated local user with low privileges can exploit this by simply reading the nohup.out file of another user's nohup process. Reproduction steps are publicly documented: running umask 022; nohup sh -c 'echo secret_data' && sleep 1 && ls -l nohup.out under uutils produces a -rw-r--r-- file, whereas GNU coreutils produces -rw------- (GitHub Issue, GitHub Advisory).

The primary impact is confidentiality loss: any local user on a multi-user system can read the nohup.out file and access sensitive information captured in the stdout/stderr output of commands run with nohup, such as credentials, API keys, application output, or other sensitive data. There is no integrity or availability impact. The vulnerability is limited to local access and does not directly enable privilege escalation or lateral movement, but exposed secrets could facilitate further attacks (GitHub Advisory, Red Hat Bugzilla).

A proof-of-concept is publicly available via the GitHub issue tracker, consisting of concrete bash commands that reproduce the world-readable file creation (GitHub Issue). There is no evidence of in-the-wild exploitation or threat actor attribution at this time. The EPSS score is approximately 0.009–0.012%, placing it in the 2nd percentile for exploitation likelihood. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

1. Identify target: Confirm the target system uses uutils coreutils (version ≤ 0.8.0) rather than GNU coreutils, e.g., by checking nohup --version for the uutils build.
2. Wait or monitor: Identify a user running a nohup command that may produce sensitive output (e.g., scripts that echo credentials, tokens, or application data).
3. Locate the output file: The default output file is nohup.out in the user's current working directory at the time nohup was invoked. Common locations include home directories or application directories.
4. Read the file: As any local user, run cat /home/targetuser/nohup.out or cat /path/to/workdir/nohup.out. With permissions of 0644, no elevated privileges are required to read the file.
5. Extract sensitive data: Review the file contents for credentials, API keys, application secrets, or other sensitive information captured from the nohup'd process's stdout/stderr (GitHub Issue).

• File System: Presence of nohup.out files with permissions 0644 (world-readable) in user home or working directories on systems using uutils coreutils; check with find / -name nohup.out -perm /o+r 2>/dev/null.
• Logs: Access log entries (e.g., from auditd) showing a user reading another user's nohup.out file — look for open or read syscalls on nohup.out by a UID different from the file owner.
• Process: Unexpected cat, less, strings, or similar read commands targeting another user's working directory or home directory files by a low-privileged user.

The GitHub Advisory notes that no patched version has been formally released as of the advisory date (affected versions ≤ 0.8.0), though a fix is tracked upstream (GitHub Advisory). Users should update uutils coreutils to a patched version once available. As immediate workarounds: (1) set umask 0077 before running nohup to ensure the output file is created with 0600 permissions; (2) manually restrict permissions after creation with chmod 600 nohup.out; or (3) explicitly redirect nohup output to a pre-created file with restricted permissions (e.g., install -m 600 /dev/null myout.log && nohup command >> myout.log). On shared systems, consider switching to GNU coreutils where nohup enforces 0600 by default (Red Hat Bugzilla).

The vulnerability was reported by a Canonical-affiliated researcher (labeled reported-canonical in the upstream issue) and tagged as a good first issue for new contributors, indicating the maintainers view it as a straightforward fix (GitHub Issue). Red Hat opened a tracking bug classifying it as low severity, and the Yocto Project security mailing list also discussed the issue, reflecting awareness across embedded Linux communities (Red Hat Bugzilla). An oss-security mailing list post was published in Q2 2026, and Ubuntu's discourse forum discussed the broader context of Rust coreutils adoption.