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 world-rea

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