high · 7.1CVE-2026-35341Jul 6, 2026

CVE-2026-35341: uu_mkfifo Unauthorized Permission Overwrite on Existing Files

Shubham Kandhare
Security Engagement Manager, SecureLayer7

A missing 'continue' in uutils mkfifo lets a failed FIFO creation silently overwrite the permissions of whatever file was already at that path, potentially making private files like SSH keys…

Packageuu_mkfifo
Ecosystemrust
Affected< 0.6.0
Fixed in0.6.0

The problem

The mkfifo loop in uu_mkfifo iterates over each target path. When the syscall fails because the path already exists, the code prints an error but does not skip the rest of the loop body.

Execution falls through to fs::set_permissions, which applies the default FIFO mode (0o666 masked by umask, typically 0644) to the pre-existing file. Any file the calling user owns can have its permissions relaxed without the user intending to do so.

Proof of concept

A working proof-of-concept for CVE-2026-35341 in uu_mkfifo, with the exact payload below.

bash
# Create a sensitive file with no permissions
touch ~/.ssh/id_rsa_test
chmod 000 ~/.ssh/id_rsa_test

# Trigger the bug: pass the sensitive file as the first argument alongside new FIFOs
coreutils mkfifo ~/.ssh/id_rsa_test fifo_a fifo_b
# Output: mkfifo: cannot create fifo '/home/user/.ssh/id_rsa_test': File exists

# Verify permissions were silently changed
ls -la ~/.ssh/id_rsa_test
# -rw-r--r-- 1 user user 0 ...  id_rsa_test   <-- was 000, now 644

The vulnerable loop body in mkfifo.rs (pre-0.6.0) calls nix::sys::stat::mkfifo(path, mode), checks the result, prints an error on failure, but then unconditionally calls fs::set_permissions(path, Permissions::from_mode(mode)) on the same path. The missing continue; after the error branch is the entire root cause (CWE-732 / CWE-281).

PR #10376 adds continue; immediately after the error is emitted, so the permissions call is only reached when FIFO creation actually succeeded. GNU coreutils never had this bug because its C implementation uses a single combined syscall path that does not reach the chmod step if mknod fails.

The fix

Upgrade uu_mkfifo (part of the uutils/coreutils package) to version 0.6.0 or later. The one-line fix in PR #10376 inserts continue; after the FIFO-creation error branch, ensuring set_permissions is never called on a path where creation failed. No configuration workaround exists for older versions.

Reported by Zellic (uutils coreutils Program Security Assessment for Canonical, Jan 2026, Finding 3.8).

References: [1][2][3][4][5]

Related research