Cloudanix VulnDB

CVE-2026-35357

Medium · 4.7

CVSS

4.7

EPSS

0.1%

Published

Apr 22, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A local user on a shared system may be able to briefly catch and read a private file while it is being copied before its permissions are fully locked down.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
High
Impact
Data Exposure
Component
Application
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw is a local information disclosure race condition in the uutils coreutils implementation of cp. When copying a file that should end up with restrictive permissions, such as 0600, the destination may first be created using permissions derived from the process umask, such as 0644, and only later tightened to the intended final mode. A local low-privileged user who can access the destination directory can repeatedly attempt to open the newly created destination file during that short window. If successful, the attacker keeps a readable file descriptor even after permissions are corrected, allowing disclosure of the copied file contents. The issue does not directly allow code execution, privilege escalation, data modification, or denial of service, but it can expose highly sensitive data if privileged or automated workflows copy secrets, credentials, keys, backups, or private configuration files using the vulnerable utility.

Why it matters to the business

Organizations using uutils coreutils may unintentionally expose sensitive files to local users on shared systems, build servers, developer workstations, CI runners, containers, or multi-user Unix-like hosts. The main risk is confidentiality loss: private keys, credentials, tokens, application configuration, customer data extracts, or backups could be read by an unprivileged local account if copied through the vulnerable cp implementation. The CVSS score is moderate and EPSS is very low with no known KEV listing or public exploit maturity reported, so broad opportunistic exploitation is not currently indicated; however, the impact can still be serious in environments where untrusted local users or workloads share the same host.

How an attack unfolds

An attacker needs local access to the same system and the ability to observe or predict where a sensitive file will be copied. The attacker monitors a writable or searchable destination directory, or repeatedly attempts to open likely destination filenames while another user, script, package process, deployment task, or privileged automation invokes the vulnerable uutils cp. During the copy operation, cp creates the destination file with initially broader umask-derived permissions before applying the final restrictive mode. If the attacker opens the file during this race window, the operating system grants a readable file descriptor based on the temporary permissions. When cp later tightens the file mode, the already-open descriptor remains valid, so the attacker can continue reading the file contents despite the final permissions showing as restricted. Successful exploitation is timing-dependent and local, but can be automated with tight polling or filesystem notification techniques.

How to fix it

Upgrade uutils coreutils to a version that contains the vendor fix when an official fixed release is available. No fixed version was provided in the input, so security teams should track the uutils coreutils upstream advisory, distribution package advisories, and language/package ecosystem releases for the patched version. Until patching is available, reduce exposure by avoiding the vulnerable uutils cp for sensitive-file copy operations; use a non-vulnerable implementation or safer copy pattern that creates the destination with restrictive permissions from the start. For sensitive automation, create destination files with mode 0600 or more restrictive before writing, copy into private directories not accessible to untrusted users, use temporary files in protected directories, and atomically rename only after permissions and ownership are correct. Ensure service accounts and build/deployment users have restrictive umasks where feasible, but do not rely on umask alone as a complete mitigation. On shared systems, restrict local shell access, isolate untrusted workloads, and prevent untrusted users from accessing directories where sensitive files are copied.

How to confirm the fix worked

Confirm whether systems are using uutils coreutils rather than another coreutils implementation by checking package inventory, binary provenance, and cp version output where available. Validate remediation by confirming the installed uutils coreutils package is at or above the vendor-fixed version once published. For exposure testing in a safe non-production environment, copy a file intended to become restrictive, such as mode 0600, into a directory accessible to a low-privileged test user while that user continuously attempts to open the destination path; a patched implementation should not allow the low-privileged user to obtain a readable descriptor at any point. Review scripts and automation that copy secrets or private files and verify they either use a patched cp or copy through a safe pattern that creates files with restrictive permissions from the outset.

Typical attack path

  1. Obtain low-privileged local access to a system using the vulnerable uutils coreutils cp implementation.
  2. Identify workflows, scripts, package operations, backups, deployments, or user actions that copy sensitive files into predictable locations.
  3. Monitor the destination directory or repeatedly attempt to open likely destination paths as files are created.
  4. Win the race while cp has created the destination with broader umask-derived permissions but before it applies the final restrictive mode.
  5. Keep the readable file descriptor open after permissions are tightened.
  6. Read sensitive contents from the retained descriptor and exfiltrate or reuse the disclosed data.

How to detect it

There are no unique network indicators for this vulnerability because exploitation is local and relies on a short file-permission race. To investigate possible prior exploitation, focus on host telemetry from shared systems where uutils cp was used to copy sensitive files. Review auditd, Linux Audit Framework, eBPF/EDR file telemetry, shell history, process execution logs, and filesystem monitoring around the times sensitive copy operations occurred. Look for low-privileged users or processes repeatedly opening, statting, or polling newly created sensitive destination files, especially immediately after cp starts and before or during chmod/fchmod activity. Useful artifacts include bursts of open/openat/access/stat/inotify activity against the same destination path by a user other than the copying account, successful read access to files whose final mode should have denied that user, suspicious scripts looping over predictable filenames, and unexpected reads from file descriptors after permissions were tightened. Correlate process execution of cp with audit events for file creation, permission changes, and read opens by unrelated local accounts. Because successful exploitation may leave no content-specific artifact, absence of logs does not prove non-exploitation unless syscall-level file access auditing was already enabled.

What your security team should do

  • Inventory systems, containers, CI images, developer workstations, and build environments that include uutils coreutils.
  • Prioritize remediation on multi-user systems, shared build hosts, CI/CD runners, container hosts, bastion systems, and environments where untrusted local users or workloads coexist with sensitive file-copy operations.
  • Track upstream and distribution advisories for the fixed uutils coreutils release, then patch or rebuild affected base images and packages promptly.
  • Temporarily replace vulnerable sensitive-file copy workflows with a safe implementation or a pattern that writes into a private directory using restrictive permissions from file creation.
  • Harden local access controls by limiting interactive shell access, isolating untrusted workloads, and preventing untrusted users from reading or traversing directories where secrets are staged or copied.
  • Search automation, deployment scripts, backup jobs, and secret-handling workflows for use of cp and review whether destination paths may be accessible to lower-privileged users.
  • Enable or tune audit logging on high-risk shared systems to capture suspicious repeated open attempts against sensitive destination paths during copy operations.

The record

The cp utility in uutils coreutils is vulnerable to an information disclosure race condition. 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.

Affected packages

Ecosystem Package Introduced Fixed
crates.io coreutils 0 No fix

Related vulnerabilities