CVE-2026-35341: 
Rust vulnerability analysis and mitigation

CVE-2026-35341 is a TOCTOU (Time-of-Check to Time-of-Use) race condition and incorrect permission assignment vulnerability in the mkfifo utility of uutils coreutils (the Rust reimplementation of GNU coreutils). When mkfifo fails to create a FIFO because a file already exists at the target path, it incorrectly continues to execute a follow-up set_permissions call instead of aborting, allowing unauthorized modification of permissions on the existing file. Affected versions are uutils coreutils ≤ 0.8.0 (Rust/cargo package). The vulnerability was reported on January 3, 2026, and published to the GitHub Advisory Database on April 22, 2026. It carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory, GitHub Issue).

The root cause is classified as CWE-732 (Incorrect Permission Assignment for Critical Resource). The mkfifo implementation in uutils coreutils performs FIFO creation and a subsequent path-based chmod via std::fs::set_permissions as two separate, non-atomic operations. When FIFO creation fails because a file already exists, the code fails to terminate processing for that path and proceeds to call set_permissions on the existing file, changing its permissions to the mode specified (or the default, often 644 after umask). Additionally, a TOCTOU race condition exists: between the failed mkfifo call and the set_permissions call, an attacker with write access to the containing directory can replace the target path with a symlink pointing to an arbitrary file (e.g., /etc/shadow or an SSH private key), causing set_permissions to modify the permissions of that sensitive target file instead (GitHub Issue, GitHub Advisory).

A local attacker with low privileges and write access to a directory can exploit this vulnerability to change the permissions of arbitrary sensitive files on the system — including SSH private keys, /etc/shadow, or other credential files — making them world-readable or otherwise accessible to unauthorized users. This results in high confidentiality and integrity impact: sensitive credentials can be read by other local users, and file permission integrity is compromised. There is no direct availability impact, but exposure of SSH private keys or shadow password hashes could enable lateral movement, privilege escalation, or account compromise (GitHub Advisory, GitHub Issue).

A proof-of-concept exploit is publicly available in the GitHub issue tracker, demonstrating the race condition attack using two concurrent shell loops — one replacing the target path with a symlink, and the other repeatedly invoking mkfifo with elevated privileges. The EPSS score is approximately 0.006% (0th percentile), indicating low current probability of exploitation in the wild. There is no evidence of active in-the-wild exploitation or threat actor attribution at this time, and the vulnerability is not listed in the CISA KEV catalog. Qualys has added detection for this vulnerability (plugin/detection ID 5011602) (GitHub Issue, GitHub Advisory).

1. Reconnaissance: Identify systems running uutils coreutils ≤ 0.8.0 where mkfifo is invoked by a privileged process or user (e.g., a script running as root or a setuid binary) on a directory writable by the attacker.
2. Set up the race (Terminal 1 — attacker): In a directory writable by the attacker, run a loop to continuously replace the target path with a symlink pointing to a sensitive file:

   while true; do rm -f /tmp/fifo; ln -s /etc/shadow /tmp/fifo; done

3. Trigger mkfifo (Terminal 2 — privileged victim process): Simultaneously, trigger or wait for the privileged process to run mkfifo on the same path:

   while true; do rm -f /tmp/fifo; mkfifo -m 0666 /tmp/fifo; done

4. Win the race: When the attacker's symlink is in place at the moment mkfifo calls set_permissions, the permissions of the symlink target (e.g., /etc/shadow) are changed to the specified mode (e.g., 0644), making it world-readable.
5. Access the sensitive file: The attacker can now read the previously protected file (e.g., cat /etc/shadow) and use the exposed credentials for further privilege escalation or lateral movement (GitHub Issue).

• File System: Unexpected permission changes on sensitive files such as /etc/shadow, ~/.ssh/id_rsa, or other credential files (e.g., permissions changed to 644 or world-readable); presence of symlinks in world-writable directories (e.g., /tmp) pointing to sensitive system files.
• Logs: Audit log entries (auditd) showing chmod/fchmod syscalls on sensitive files by unexpected processes or users; inotifywait or filesystem audit events on /etc/shadow or SSH key files indicating permission changes.
• Process: Repeated rapid creation and deletion of files or symlinks in /tmp or other shared directories by low-privileged users; mkfifo invocations in tight loops visible in process listings (ps, top) or shell history.
• Network: Subsequent unauthorized SSH login attempts using exposed private keys from systems where keys were made world-readable.

The GitHub Advisory (GHSA-w8m4-4v35-v6x3) lists all versions ≤ 0.8.0 as affected, with no patched version listed as of the advisory publication date — users should monitor the uutils/coreutils repository for a fix. As a workaround, restrict access to the mkfifo binary to trusted users only, avoid running mkfifo with elevated privileges on directories writable by untrusted users, and audit permissions on sensitive files (especially SSH private keys and /etc/shadow) to detect unauthorized changes. Additionally, consider using GNU coreutils mkfifo as an alternative until a patched uutils version is released (GitHub Advisory, GitHub Issue).

Ubuntu published a discussion on the Rust coreutils transition in response to this and related issues, noting the security implications of replacing GNU coreutils with the uutils Rust implementation (Ubuntu Discourse). The vulnerability was also discussed on the oss-security mailing list and flagged by the Yocto Project security team, indicating concern in embedded Linux communities about the impact on distributions shipping uutils coreutils (oss-sec). The issue was assigned the label good first issue in the uutils repository, suggesting the maintainers view the fix as approachable for new contributors.