CVE-2026-35351

What it actually does

The uutils coreutils implementation of mv mishandles moves that cross filesystem boundaries. When a same-filesystem rename is not possible, mv falls back to copying the source and deleting the original, but the copied destination is created with the caller's UID/GID instead of preserving the source file's ownership metadata. If a privileged user or automation runs the move, files that previously belonged to an application or user can become owned by root or another executing account. This can cause unintended access changes, loss of expected write access, backup or migration corruption, and possible information disclosure or integrity issues where ownership is used as part of an access-control model.

Why it matters to the business

The main operational risk is silent data-permission drift during backups, restores, migrations, package operations, or administrative file moves. Organizations using uutils coreutils could end up with files that applications or users can no longer modify, causing service failures, failed restores, broken deployments, or support incidents. Because the flaw requires local privileged execution and has low EPSS, broad internet-scale exploitation is unlikely; however, the impact can be significant in automation-heavy environments where mv is used by root across mount points, containers, volumes, or backup filesystems.

How an attack unfolds

An attacker needs local access and the ability to influence a privileged move operation, such as by placing files in a directory that an administrator, backup script, migration job, or maintenance process later moves across filesystem boundaries. When uutils mv attempts the move, it cannot perform a simple rename between filesystems, so it copies the file to the destination and removes the original. Due to the flaw, the destination is owned by the user running mv rather than the original owner. If that user is root, attacker-controlled or user-owned files may become root-owned. Depending on surrounding permissions and workflows, this may deny legitimate users access, expose data to a more privileged processing context, or interfere with applications that rely on file ownership for security decisions. There is no indication of known exploitation, KEV listing, ransomware use, or mature public exploit activity in the provided data.

How to fix it

Upgrade uutils coreutils to a version that explicitly fixes ownership preservation during cross-filesystem mv operations once a fixed release is available from the vendor or distribution. No fixed version was provided in the input, so track the upstream uutils coreutils advisory and downstream operating-system package advisories. Until patched, avoid using the affected uutils mv for privileged cross-filesystem moves. Use a known-good coreutils implementation or safer copy tooling that preserves ownership, such as cp -a, rsync -a, install with explicit ownership, or tar-based transfer workflows, followed by verification before deleting the source. For automation, add explicit chown/chgrp restoration after moves where ownership matters. Restrict who can trigger privileged move jobs and review scripts that move user, application, backup, or restore data across mount points.

How to confirm the fix worked

Confirm which mv implementation is in use by checking the package source and binary path, for example whether mv comes from uutils coreutils rather than GNU coreutils or another implementation. Test exposure in a non-production location by creating a file owned by a non-root test account on one filesystem, then moving it as root to a different filesystem with the affected mv; if the destination becomes root-owned instead of retaining the source owner, the system is vulnerable. After remediation or mitigation, repeat the same cross-filesystem move test and confirm the original UID/GID are preserved. Review backup, migration, deployment, and restore scripts for mv operations that cross mounts or devices. Validate production data integrity by sampling critical destination trees for unexpected ownership changes after recent move operations.

Typical attack path

1. Gain local access to a system or influence files handled by a privileged maintenance, backup, restore, or migration workflow.
2. Place or modify files in a source location that will later be moved using uutils coreutils mv.
3. Ensure the move crosses a filesystem boundary, such as between mounts, volumes, devices, containers, or backup targets.
4. Wait for a privileged user or automated job to run mv across that boundary.
5. The vulnerable mv copies the file to the destination using the caller's UID/GID instead of preserving the original ownership.
6. Use the resulting ownership mismatch to cause access denial, disrupt services, or take advantage of workflows that trust destination ownership.

How to detect it

There is no known public exploitation or KEV activity indicated, so detection should focus on identifying harmful ownership changes after cross-filesystem moves rather than looking for a network exploit. Review shell history, sudo logs, auditd, process accounting, EDR telemetry, and automation logs for privileged mv executions involving paths on different filesystems or mounted volumes. Correlate those events with file metadata changes where destination files became owned by root or the mv caller instead of their prior owner. Useful log sources include Linux audit logs for execve events, sudo/auth logs for privileged mv commands, backup and migration job logs, CI/CD runner logs, container build logs, configuration-management logs, and filesystem integrity monitoring records. For forensics, compare source metadata from backups, snapshots, manifests, package databases, or prior file integrity baselines against current destination ownership. Investigate clusters of unexpected ownership changes in application data directories, user home directories, backup restores, shared volumes, and container bind mounts following administrative move operations.

What your security team should do

• Inventory systems and containers using uutils coreutils, especially where it replaces standard coreutils in base images, developer environments, embedded systems, or Rust-based distributions.
• Prioritize remediation for servers and automation hosts that run privileged backups, migrations, restores, deployments, or volume-management tasks across filesystem boundaries.
• Until a fixed version is available, replace vulnerable mv usage in privileged scripts with ownership-preserving alternatives such as rsync -a or cp -a followed by verified source removal.
• Add post-move ownership validation to critical backup and migration workflows, and fail jobs if ownership differs from expected metadata.
• Review recent cross-filesystem move activity for unexpected root-owned or service-account-owned files in application, user, backup, and restore directories.
• Monitor vendor and distribution advisories for the exact fixed uutils coreutils release and roll it into base images and configuration-management baselines.
• Treat this as a local operational-integrity issue rather than an internet-facing emergency, but address it promptly where ownership errors could break services or expose sensitive data.