CVE-2026-35374

What it actually does

This is a local time-of-check to time-of-use race condition in the uutils coreutils implementation of the split utility. The utility checks whether the input and output refer to the same file using path-based validation, but later opens the output file with truncation after that check has completed. Because path components can change between validation and use, a local user with write access to the target directory can replace or redirect a path, such as by swapping in a symbolic link, causing split to truncate or overwrite a different file than the one originally validated. The primary impacts are file integrity loss and availability loss for files writable by the user or by the process executing split.

Why it matters to the business

Successful exploitation can permanently corrupt or delete important local files by truncating them during a split operation. The risk is highest on shared systems, build workers, automation hosts, CI/CD runners, package-processing services, and any workflow where split may operate in directories writable by less-trusted users. The vulnerability is not remotely exploitable by itself, has high attack complexity, is not known to be exploited in the wild, is not in the CISA KEV catalog, and has a very low, flat EPSS score, so remediation should be prioritized based on local multi-user exposure and use of uutils coreutils rather than broad internet-facing urgency.

How an attack unfolds

An attacker first needs local access and permission to write in a directory used by a split operation. They observe or predict a workflow that invokes the uutils coreutils split utility with output paths in that writable directory. During the small race window after split validates the input and output file paths but before it opens the output file for writing, the attacker changes a mutable path component, for example by replacing a directory entry with a symbolic link. When split subsequently opens the output path with truncation, the path may resolve to an unintended target. If the process has permission to write that target, the file may be truncated or overwritten, causing data loss or disruption. Exploitation is constrained by local access, timing, filesystem permissions, and knowledge or control of the working directory used by the victim process.

How to fix it

Upgrade uutils coreutils to a version containing the vendor fix when one is available. No fixed version was provided in the input, so track the upstream uutils coreutils advisory, release notes, and distribution package updates for the corrected build. Until patched, avoid running uutils split on paths located in directories writable by untrusted users. Use trusted, private working directories with restrictive permissions, avoid predictable output prefixes in shared directories, and prevent automated jobs from invoking split with elevated privileges on attacker-controllable paths. Where possible, use a coreutils implementation or wrapper that safely opens output files using race-resistant file descriptor handling rather than path-only checks. Review scripts, CI jobs, data-processing pipelines, and package/build automation that call split in shared temporary directories or world-writable locations.

How to confirm the fix worked

Confirm the installed split binary is from uutils coreutils and verify its package version against the upstream or distribution-fixed release once published. Inventory systems using uutils coreutils rather than GNU coreutils, especially build hosts, developer workstations, containers, and automation images. Validate that workflows invoking split do not use world-writable or group-writable directories for output unless protected by sticky-bit semantics and strict ownership controls. After patching, rerun package/version checks in base images and deployed hosts. For mitigation validation, confirm output directories used by split are owned by the executing account, are not writable by untrusted users, and are not symlinks or path components controlled by less-trusted principals.

Typical attack path

1. Gain local access to a system where uutils coreutils is installed.
2. Identify a workflow, script, or user action that runs the uutils split utility in a directory the attacker can modify.
3. Prepare a race condition by controlling or monitoring an output path component used by split.
4. Wait for split to complete its path-based identity check between input and output files.
5. Rapidly replace the checked path component with a symbolic link or other filesystem redirection to an attacker-chosen target.
6. Allow split to open the redirected output path with truncation.
7. Cause truncation or overwrite of a file writable by the split process, resulting in data corruption or denial of service.

How to detect it

Detection should focus on evidence of local race-condition abuse around executions of the uutils split utility. Useful telemetry includes process execution logs, auditd or equivalent file integrity events, EDR process/file events, shell history where available, CI/build logs, and filesystem metadata change logs. Look for split executions in world-writable or shared directories, especially followed closely by symlink creation, rename operations, unlink operations, or unexpected truncation of files. Investigate sudden zero-byte or unexpectedly shortened files whose modification time aligns with a split process. On Linux systems with auditd, monitor for execve events involving split and file events such as symlink, rename, open with truncation, and unlink in the same directory and time window. In automation environments, review build logs for split operations using /tmp, shared workspaces, mounted volumes, or attacker-writable directories. There are no known public exploit campaigns, named threat actors, ransomware usage, or stable payload indicators for this vulnerability, so detection is behavioral rather than signature-based.

What your security team should do

• Inventory where uutils coreutils is installed and distinguish it from GNU coreutils in hosts, containers, developer tooling, and build images.
• Prioritize remediation on shared Linux/Unix systems, CI/CD runners, build farms, automation servers, and data-processing services where untrusted users can write to directories used by split.
• Track the upstream uutils coreutils fix and apply the first fixed package or distribution update when available.
• Until a fix is deployed, prohibit use of split in world-writable, group-writable, or otherwise untrusted directories.
• Review scripts and automation for split invocations using temporary directories, predictable output prefixes, or elevated privileges.
• Harden filesystem permissions for working directories used by scheduled jobs and service accounts.
• Monitor for unexpected truncation, sudden zero-byte files, or file replacement events around split executions on shared systems.
• Treat confirmed exploitation as a local integrity incident and investigate adjacent user activity, symlink creation, and file modification events.