CVE-2026-35341

What it actually does

This is a local authorization bypass in uutils coreutils `mkfifo`. When `mkfifo` is asked to create a FIFO at a path where a file already exists, it correctly encounters a creation failure, but then incorrectly continues processing and applies a follow-up permission-setting operation to the existing file. As a result, an existing regular file, key file, configuration file, or other sensitive path can have its permissions changed to the default requested mode, commonly world-readable such as `0644` depending on umask and invocation context. The vulnerability does not provide remote code execution by itself; exploitation requires local access and a vulnerable `mkfifo` execution path with sufficient privileges over the target file.

Why it matters to the business

An attacker with local access may be able to cause sensitive files to become readable or writable by users who should not have access, potentially exposing SSH private keys, credentials, application secrets, or security configuration. The operational risk is highest on multi-user systems, build hosts, CI runners, shared development servers, containers using uutils coreutils, and automation that invokes `mkfifo` as a privileged user. Although EPSS is currently low and there is no known KEV listing or mature public exploitation, the flaw is simple to exploit locally when a vulnerable workflow exists, so affected systems should be reviewed and remediated as part of host hardening and package management.

How an attack unfolds

An attacker first obtains local, low-privileged access to a system that uses the uutils implementation of `mkfifo`. The attacker then identifies a privileged script, service, installer, cleanup job, container entrypoint, or administrator workflow that runs `mkfifo` on a path the attacker can influence, predict, or pre-create. Instead of allowing the FIFO to be created, the attacker ensures that the target path already resolves to an existing sensitive file or a file whose permissions should remain restricted. When the vulnerable `mkfifo` runs, the creation step fails because the file exists, but the program continues and applies default permissions to that existing file. If the process has ownership or sufficient privileges, the sensitive file’s mode may be relaxed, allowing other local users to read or potentially modify it. The attacker then accesses the newly exposed file, such as an SSH private key or secret-bearing configuration, and uses the disclosed material for lateral movement, privilege escalation, or data theft.

How to fix it

Upgrade uutils coreutils to a version that explicitly fixes this behavior once a vendor-fixed release is available. No fixed version was provided in the input, so security teams should monitor the uutils coreutils project, operating system package advisories, container base image updates, and distribution security feeds for the corrected package. Where immediate upgrade is not available, use an unaffected `mkfifo` implementation, such as the platform’s GNU coreutils implementation where appropriate, or remove the vulnerable uutils `mkfifo` from privileged execution paths. Review scripts and services that call `mkfifo` and ensure they fail closed when the destination path already exists, validate target directories, avoid following attacker-controlled paths, and do not run with elevated privileges unless required. As compensating controls, restrict local shell access, enforce least privilege, isolate CI/build workloads, mount sensitive secrets with restrictive permissions, and monitor for unexpected permission changes on key material and configuration files.

How to confirm the fix worked

Confirm exposure by checking whether `mkfifo` is supplied by uutils coreutils on each host, container image, and build environment, for example by reviewing package inventory and the output of `mkfifo --version` where available. Validate remediation by reproducing the safe behavior in a non-production test directory: create a file with restrictive permissions such as `0600`, run the patched `mkfifo` against the same path, and verify that the command fails without changing the existing file’s permissions. Also verify that privileged scripts and services do not call `mkfifo` on attacker-controlled or pre-existing paths. After remediation, scan sensitive files such as SSH keys, secret files, service credentials, and security configuration for overly broad permissions, especially files that should be `0600` or `0640` but are now `0644`, `0664`, or `0666`.

Typical attack path

1. Gain local access to a host using uutils coreutils.
2. Confirm that `mkfifo` is provided by the vulnerable uutils implementation rather than a fixed build or an unaffected implementation.
3. Identify a privileged or higher-trust process that invokes `mkfifo` on a predictable or attacker-influenced path.
4. Ensure the target path already exists as, or resolves to, a sensitive file whose permissions should remain restricted.
5. Trigger the privileged `mkfifo` execution so that FIFO creation fails with a file-exists condition.
6. Rely on the vulnerable follow-up permission change to relax the permissions of the existing file.
7. Read or modify the exposed file, such as private keys, credentials, tokens, or configuration files.
8. Use the obtained access or secrets for further compromise, persistence, or lateral movement.

How to detect it

To determine whether this was already exploited, review host telemetry for suspicious `mkfifo` executions followed by permission changes on existing files. Useful sources include auditd logs, EDR process and file events, shell history, sudo logs, cron logs, systemd journal entries, CI job logs, container runtime logs, and file integrity monitoring. Look for `mkfifo` executions that returned a file-exists error and were followed by `chmod`, `fchmod`, or `fchmodat` activity on the same path. Pay special attention to sensitive files whose permissions changed from restrictive modes such as `0600` or `0640` to broader modes such as `0644`, `0664`, or `0666`. Investigate any world-readable SSH private keys, credential files, API tokens, service configuration files, Kubernetes or cloud credentials, and application secret files. If auditd is available, search for `comm="mkfifo"` or executable paths ending in `/mkfifo` combined with chmod-family syscalls. Because there are no public campaign-specific indicators, detection should focus on behavioral evidence of abnormal permission changes rather than network indicators.

• comm="mkfifo"
• /usr/bin/mkfifo
• /bin/mkfifo
• /usr/local/bin/mkfifo
• mkfifo: cannot create fifo
• File exists
• syscall=chmod
• syscall=fchmod
• syscall=fchmodat
• chmod 0644
• chmod 0666
• mode=0644
• mode=0666
• .ssh/id_rsa
• /.ssh/id_ed25519
• .ssh/id_dsa
• .ssh/id_ecdsa

What your security team should do

• Inventory systems and container images that use uutils coreutils, especially servers, CI runners, development hosts, build images, and minimal OS images.
• Prioritize remediation on multi-user systems and any environment where untrusted users can influence filesystem paths used by privileged scripts.
• Replace or upgrade the vulnerable `mkfifo` implementation as soon as a fixed package is available from the relevant distribution or upstream project.
• Review privileged automation, init scripts, installers, and container entrypoints for `mkfifo` calls using predictable, shared, or user-controllable paths.
• Deploy monitoring for permission changes on sensitive files, including SSH private keys, credential files, service account secrets, and application configuration.
• Use auditd, EDR, or eBPF telemetry to alert when a process named `mkfifo` performs `chmod`, `fchmod`, or `fchmodat` operations on an existing file after a file-exists error.
• Harden local access controls and segregate untrusted users or builds while affected systems remain unpatched.
• After patching, perform a one-time permission audit to identify sensitive files that may already have been made world-readable or group-readable.