CVE-2026-35367: uutils coreutils Information Disclosure

CVE-2026-35367 Overview

The nohup utility in uutils coreutils creates its default output file, nohup.out, without specifying explicit restricted permissions. This causes the file to inherit umask-based permissions, typically resulting in a world-readable file (0644). In multi-user environments, this allows any user on the system to read the captured stdout/stderr output of a command, potentially exposing sensitive information. This behavior diverges from GNU coreutils, which creates nohup.out with owner-only (0600) permissions.

Critical Impact

Sensitive command output may be exposed to unauthorized local users in shared multi-user environments due to overly permissive file permissions on nohup.out.

Affected Products

• uutils coreutils (nohup utility)

Discovery Timeline

• 2026-04-22 - CVE CVE-2026-35367 published to NVD
• 2026-04-22 - Last updated in NVD database

Technical Details for CVE-2026-35367

Vulnerability Analysis

This vulnerability falls under CWE-732 (Incorrect Permission Assignment for Critical Resource). When users execute background processes using the nohup utility from uutils coreutils, the utility creates an output file called nohup.out to capture stdout and stderr streams. The fundamental issue is that the uutils implementation does not explicitly set restrictive file permissions when creating this output file.

The file creation relies on the system's default umask settings, which typically result in permissions of 0644 (rw-r--r--). This means the file owner can read and write, while all other users on the system can read the file's contents. This is a significant deviation from the expected behavior established by GNU coreutils, which explicitly creates nohup.out with 0600 permissions (owner-only access).

In multi-user systems such as shared servers, academic computing environments, or enterprise workstations, this can lead to inadvertent information disclosure. Any process output that contains sensitive data—including database credentials, API keys, configuration details, or proprietary information—could be read by any authenticated user on the system.

Root Cause

The root cause is the absence of explicit permission specification in the file creation logic of the uutils coreutils nohup implementation. When opening the output file, the code does not include flags or calls to restrict the file mode, allowing the default umask to determine the final permissions. GNU coreutils addresses this by explicitly setting the file mode to 0600 during file creation, ensuring owner-only access regardless of the system umask.

Attack Vector

The attack vector requires local access to the system. An attacker with a valid user account on a multi-user system can exploit this vulnerability through the following scenario:

1. A legitimate user executes a long-running process using nohup command &
2. The nohup utility creates nohup.out with world-readable permissions (0644)
3. The command produces output containing sensitive information (credentials, tokens, internal data)
4. Any other authenticated user on the system can read the contents of nohup.out
5. The attacker extracts sensitive information from the exposed file

This vulnerability does not require any special privileges beyond standard user access, and no user interaction is needed beyond the victim running a nohup command that produces sensitive output.

Detection Methods for CVE-2026-35367

Indicators of Compromise

• Presence of nohup.out files with world-readable permissions (0644 or similar) in user directories or working directories
• File access logs showing reads of nohup.out files by users other than the file owner
• Unusual access patterns to home directories or project directories by non-owners

Detection Strategies

• Implement file integrity monitoring to detect nohup.out files created with permissive access modes
• Use audit logging (auditd on Linux) to track file access events on sensitive directories
• Run periodic scans using find / -name "nohup.out" -perm /o+r to identify world-readable nohup output files

Monitoring Recommendations

• Enable system auditing for file read operations in multi-user environments
• Configure alerts for nohup.out file creation events in sensitive directories
• Implement centralized logging to correlate file access patterns across user accounts

How to Mitigate CVE-2026-35367

Immediate Actions Required

• Set a restrictive umask (e.g., umask 077) before running nohup commands to ensure output files are created with owner-only permissions
• Explicitly specify an output file with restricted permissions using nohup command > /path/to/secure_output 2>&1 & after pre-creating the file with proper permissions
• Review existing nohup.out files on shared systems and restrict permissions using chmod 600 nohup.out
• Consider switching to GNU coreutils if the secure default behavior is critical for your environment

Patch Information

No official patch has been confirmed at this time. Users should monitor the GitHub Issue Discussion for updates on a fix. The expected resolution would involve modifying the nohup utility to explicitly set file permissions to 0600 when creating nohup.out, aligning with GNU coreutils behavior.

Workarounds

• Use a restrictive umask before running nohup: umask 077 && nohup command &
• Redirect output to a pre-created file with restricted permissions instead of relying on the default nohup.out
• Create a wrapper script that enforces secure umask settings before invoking nohup
• On critical systems, avoid using the uutils nohup utility until a patch is available

# Configuration example
# Set restrictive umask before running nohup to mitigate the vulnerability
umask 077
nohup /path/to/your/command &

# Alternative: Pre-create output file with secure permissions
touch /tmp/secure_output.log
chmod 600 /tmp/secure_output.log
nohup /path/to/your/command > /tmp/secure_output.log 2>&1 &