CVE-2026-35357: uutils coreutils Race Condition Vulnerability

CVE-2026-35357 Overview

The cp utility in uutils coreutils is vulnerable to an information disclosure race condition (CWE-367: Time-of-Check Time-of-Use). Destination files are initially created with umask-derived permissions (e.g., 0644) before being restricted to their final mode (e.g., 0600) later in the process. A local attacker can race to open the file during this window; once obtained, the file descriptor remains valid and readable even after the permissions are tightened, exposing sensitive or private file contents.

Critical Impact

Local attackers can exploit this TOCTOU race condition to read sensitive file contents that should be protected by restrictive permissions, potentially exposing credentials, private keys, or other confidential data.

Affected Products

• uutils coreutils cp utility

Discovery Timeline

• April 22, 2026 - CVE CVE-2026-35357 published to NVD
• April 22, 2026 - Last updated in NVD database

Technical Details for CVE-2026-35357

Vulnerability Analysis

This vulnerability represents a classic Time-of-Check Time-of-Use (TOCTOU) race condition in file permission handling. The core issue lies in how the cp utility handles file creation and permission assignment as separate, non-atomic operations.

When copying a file that should have restrictive permissions (such as 0600 for private keys or configuration files containing credentials), the cp utility first creates the destination file with permissions derived from the system's umask setting. On most systems, this results in initial permissions of 0644 or similar, which allows world-readable access. Only after the file is created does the utility modify the permissions to match the intended restrictive mode.

This temporal gap between file creation and permission restriction creates an exploitable window. A local attacker monitoring file system operations can detect when a sensitive file copy operation begins and immediately open the newly created file before permissions are tightened. The key insight is that Unix file descriptors retain their access rights even after the underlying file's permissions change—once the attacker has an open file descriptor, they can continue reading the file's contents regardless of subsequent permission modifications.

Root Cause

The root cause is the non-atomic handling of file creation and permission assignment in the cp utility. The operation sequence creates a race window where:

1. The destination file is created with umask-derived permissions (permissive)
2. File content is written to the destination
3. File permissions are modified to match the source file (restrictive)

This two-step process violates the principle of secure file creation, which requires that files with restrictive permissions be created with those permissions from the outset, never exposing them in a more permissive state.

Attack Vector

The attack requires local access to the system where the vulnerable cp utility is being used. An attacker would:

1. Monitor file system activity for copy operations targeting directories they can access
2. Detect when a new file is being created by the cp utility
3. Rapidly open the file while it still has permissive umask-derived permissions
4. Retain the file descriptor and read contents even after permissions are tightened

The attack is timing-sensitive but can be automated using inotify or similar file system notification mechanisms to detect file creation events in real-time. The attacker does not need elevated privileges—only the ability to read files in the target directory during the race window.

Detection Methods for CVE-2026-35357

Indicators of Compromise

• Unusual file access patterns where processes open files immediately after creation in monitored directories
• Multiple rapid open/read operations on newly created files from unexpected processes
• Processes using inotify or fanotify to monitor directories where sensitive files are being copied

Detection Strategies

• Monitor for processes that maintain file descriptors to files they no longer have permission to access
• Implement audit rules using auditd to track file open operations on sensitive directories
• Use Security-Enhanced Linux (SELinux) or AppArmor policies to restrict which processes can access sensitive file locations

Monitoring Recommendations

• Enable file access auditing on directories containing sensitive data such as /etc/, /root/, and application configuration directories
• Configure real-time alerts for anomalous file access patterns during copy operations
• Review process file descriptor tables for handles to files with restrictive permissions

How to Mitigate CVE-2026-35357

Immediate Actions Required

• Review usage of the uutils coreutils cp utility in scripts and automated processes that handle sensitive files
• Consider using alternative file copy methods that create files with correct permissions atomically
• Restrict access to directories where sensitive file copy operations occur

Patch Information

A fix for this vulnerability is being tracked in the GitHub Issue Discussion. Users should monitor this issue for patch availability and upgrade to a fixed version when released.

The proper fix involves using open() with the O_CREAT flag combined with the correct mode parameter, or using fchmod() before writing any sensitive content to the file. This ensures that restrictive permissions are applied from the moment of file creation.

Workarounds

• Use restrictive umask settings (e.g., umask 077) before running cp operations on sensitive files to minimize the race window exposure
• Copy sensitive files to directories with restricted access (mode 0700) to prevent other users from exploiting the race condition
• Use GNU coreutils cp or other implementations that handle file permissions atomically when copying sensitive files
• Consider using install -m 0600 instead of cp for copying files that require restrictive permissions