CVE-2026-35351: 
Rust vulnerability analysis and mitigation

CVE-2026-35351 is a file ownership preservation flaw in the mv utility of uutils coreutils (the Rust reimplementation of GNU coreutils). When moving files across different filesystem boundaries, the utility falls back to a copy-and-delete routine that creates the destination file using the caller's UID/GID rather than preserving the source file's ownership metadata. This affects uutils coreutils versions ≤ 0.8.0 (Rust/cargo package). The vulnerability was reported on December 19, 2025, and publicly disclosed on April 22, 2026. It carries a CVSS v3.1 base score of 4.2 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-281 (Improper Preservation of Permissions). When mv cannot perform an atomic rename across filesystem boundaries, it falls back to a copy-and-delete routine using fs::copy() and create_dir_all() without subsequently calling chown() to restore the source file's ownership on the destination. This flaw affects three specific code paths: rename_file_fallback, copy_file_with_hardlinks_helper, and copy_dir_contents_recursive. Because non-root users cannot set arbitrary ownership due to kernel restrictions, the impact is most significant when mv is executed as root — files originally owned by non-root users silently become root-owned after a cross-device move. GNU coreutils' mv correctly handles this by calling chown() after the copy step (GitHub Issue, GitHub Advisory).

Successful exploitation causes files moved by a privileged user (e.g., root) across filesystem boundaries to silently lose their original ownership, becoming owned by root instead of the intended user. This can result in information disclosure (non-owners gaining read access to files they should not) or restricted access (intended owners losing access to their own files). The impact is particularly severe in backup, migration, and administrative scripting contexts where ownership metadata integrity is assumed, potentially breaking access controls across entire directory trees (GitHub Advisory, GitHub Issue).

A proof-of-concept demonstrating the ownership loss bug is publicly available in the uutils coreutils issue tracker. Exploitation requires local access and high privileges (e.g., root), limiting the attack surface significantly. There is no evidence of in-the-wild exploitation, no threat actor attribution, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.011% (0.018% per GitHub Advisory), indicating a very low probability of exploitation in the near term (GitHub Issue, GitHub Advisory).

1. Setup: Ensure uutils coreutils (version ≤ 0.8.0) is installed and that the mv binary in use is the uutils implementation rather than GNU coreutils.
2. Create a test file with non-root ownership: As root, create a file and assign it to a non-root user: touch /tmp/testfile && sudo chown 1000:1000 /tmp/testfile.
3. Mount a separate filesystem: Mount a tmpfs (or any other filesystem) to simulate a cross-device boundary: sudo mount -t tmpfs tmpfs /mnt/other.
4. Trigger the cross-device move: Execute mv as root to move the file across the filesystem boundary: sudo mv /tmp/testfile /mnt/other/.
5. Observe ownership corruption: Verify that the destination file is now owned by root (0:0) instead of the original owner (1000:1000): ls -ln /mnt/other/testfile — output shows 0 0 for UID/GID.
6. Impact: Files in backup or migration workflows now have incorrect ownership, potentially granting root-level access or denying access to the intended owner (GitHub Issue).

• File System: Files on destination filesystems (especially tmpfs, NFS, or other cross-device mounts) unexpectedly owned by root (UID 0, GID 0) when they should be owned by non-root users; discrepancies between expected and actual file ownership in backup or migration directories.
• Logs: System audit logs (auditd) showing mv operations by root across mount points followed by ownership changes inconsistent with the original file metadata; absence of chown syscall after cross-device copy operations in strace output.
• Process: mv (uutils implementation) spawning file copy operations (fs::copy) across different device IDs without a subsequent chown call, observable via strace -e trace=file,chown sudo mv ... showing no chown/lchown syscall after the copy (GitHub Issue).

As of the GitHub Advisory (last updated April 29, 2026), no patched version of uutils coreutils has been released — all versions ≤ 0.8.0 are listed as affected with "Patched versions: None." Users should monitor the uutils coreutils repository for a fix. In the interim, administrators should use GNU coreutils mv (which correctly calls chown() after cross-device copies) for privileged file move operations, or manually run chown after cross-device moves performed by root. Implementing file integrity monitoring (e.g., AIDE, Tripwire) to detect unexpected ownership changes on critical files is also recommended (GitHub Advisory, Red Hat Bugzilla).

Red Hat tracked the issue via their security response process (Bugzilla #2460805) with medium priority and severity. The issue was originally reported by a Canonical contributor (labeled reported-canonical in the uutils tracker) and disclosed via the oss-security mailing list. Ubuntu published an update on Rust coreutils adoption in response to the disclosure. No significant broader media coverage or notable researcher commentary beyond the issue tracker and advisory databases has been identified (Red Hat Bugzilla, GitHub Issue).