CVE-2026-35345

What it actually does

This vulnerability is a local information disclosure flaw in the uutils implementation of the `tail` utility. When `tail` is used with `--follow=name` to monitor a file path, it continues following the path even after the monitored file is replaced with a symbolic link. If a privileged process or user is running uutils `tail` against a writable log directory, a lower-privileged local attacker who can replace the monitored log file can point that path to a sensitive file. The privileged `tail` process may then read and output the symlink target, disclosing contents such as password hashes, private keys, tokens, or configuration secrets. Exploitation requires local access, write permission to the monitored directory or file path, and a privileged observer using the affected uutils `tail` behavior.

Why it matters to the business

Successful exploitation can expose sensitive local files to a low-privileged user, potentially enabling credential theft, privilege escalation, lateral movement, or compromise of application secrets. The practical risk is highest on systems where administrators, service wrappers, troubleshooting scripts, containers, CI jobs, or monitoring tooling use uutils `tail --follow=name` or equivalent behavior on directories writable by less-trusted users. The vulnerability is not listed in CISA KEV, has very low EPSS, and has no reported exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, it remains important for multi-user servers, shared build environments, developer workstations, containers, and systems with delegated log-write permissions.

How an attack unfolds

An attacker first obtains local access to a system and identifies a log file or monitored path in a directory they can write to or manipulate. A privileged user or process must be running the affected uutils `tail` with `--follow=name` against that path. The attacker removes, renames, or replaces the expected log file and creates a symbolic link at the same path pointing to a sensitive file, such as `/etc/shadow` or another root-readable secret. Because the vulnerable uutils `tail` implementation continues to monitor the path after replacement, it follows the symbolic link and reads from the target file. The sensitive contents are then emitted to the privileged tail output destination, which may be a terminal, log collector, pipeline, service output, or other channel visible to the attacker or later recoverable from logs.

How to fix it

Upgrade uutils coreutils to a version containing the vendor fix as soon as one is available. No fixed version was provided in the input, so track the upstream uutils coreutils advisory, package manager security updates, and distribution backports. Where immediate patching is not available, avoid using uutils `tail --follow=name` or follow-by-name modes on paths located in directories writable by less-privileged users. Prefer a non-vulnerable implementation such as GNU coreutils `tail` where appropriate and validated. Restrict write permissions on log directories monitored by privileged users or services, ensure log directories are owned by root or the relevant service account, and prevent untrusted users from replacing monitored file names. Avoid privileged tailing of files in shared temporary directories, user-controlled application directories, container bind mounts, and build workspaces. Enable or verify OS-level symlink protections where supported, such as Linux `fs.protected_symlinks`, while recognizing that permissions and tool behavior should still be corrected. For services that pipe `tail` output into logs or collectors, review whether sensitive file content could have been captured and retained.

How to confirm the fix worked

Confirm whether uutils coreutils is installed and whether the active `tail` binary comes from uutils rather than GNU coreutils by checking package metadata, binary path, and `tail --version` output. Review scripts, service units, cron jobs, shell aliases, container images, CI jobs, and operational runbooks for `tail --follow=name`, `tail -F`, or equivalent follow-by-name usage. Verify that any monitored directories are not writable by untrusted users or groups and that the sticky bit, ownership, and ACLs do not permit unsafe file replacement. If a fixed package becomes available, confirm the installed version matches or exceeds the fixed version from the upstream or distribution advisory. To validate mitigation, test in a non-production environment that replacing a monitored file with a symlink to a protected file does not result in disclosure through the tail output. Also verify that log collectors and service output streams do not contain sensitive file fragments from prior exposure.

Typical attack path

1. Gain local low-privileged access to a host running uutils coreutils.
2. Identify use of uutils `tail --follow=name`, `tail -F`, or similar follow-by-name behavior by a privileged user, script, service, or monitoring process.
3. Find a monitored file path in a directory where the attacker can create, remove, rename, or replace files.
4. Replace the monitored log file path with a symbolic link to a sensitive file readable by the privileged tail process.
5. Wait for the affected `tail` process to reopen or continue monitoring the replaced path.
6. Read the sensitive file contents from the tail output, downstream logs, terminal scrollback, captured process output, or log aggregation destination.
7. Use disclosed secrets, password hashes, private keys, or tokens for privilege escalation or further compromise.

How to detect it

Look for evidence that privileged `tail` processes using uutils followed a file path in a writable directory shortly before or after the path was replaced with a symbolic link. Useful sources include process execution telemetry, shell history, auditd logs, EDR file events, service manager logs, cron logs, container runtime logs, CI job logs, terminal session recordings, and centralized log aggregation. Search for privileged executions of `tail --follow=name` or `tail -F`, especially where the monitored path is under an application, user, temporary, build, or container-mounted directory writable by non-root users. Correlate those executions with file deletion, rename, unlink, symlink creation, or ownership changes at the monitored path. Investigate symlinks in log directories that point to sensitive files such as `/etc/shadow`, `/etc/gshadow`, private SSH keys, cloud credential files, service account tokens, or application secret files. Review downstream logs and captured process output for fragments of sensitive files, including password hash formats, PEM key headers, token strings, or configuration secrets. Because this is a local vulnerability and no public exploitation or KEV status is indicated, prioritize high-value shared systems and any environment with untrusted local users or writable log paths.

• tail --follow=name
• tail -F
• uutils tail
• /etc/shadow
• /etc/gshadow
• /root/.ssh/id_rsa
• /root/.ssh/id_ed25519
• -----BEGIN OPENSSH PRIVATE KEY-----
• -----BEGIN RSA PRIVATE KEY-----
• $y$j9T$
• $6$
• $5$
• type=SYMLINK
• symlink("/etc/shadow"
• symlinkat("/etc/shadow"
• ln -s /etc/shadow
• ln -s /etc/gshadow
• ln -s /root/.ssh/id_rsa
• fs.protected_symlinks

What your security team should do

• Inventory systems, containers, developer images, and CI/build environments using uutils coreutils, especially where `tail` is used operationally by privileged users or services.
• Prioritize remediation on multi-user systems, shared application hosts, build agents, bastion hosts, container hosts, and systems where untrusted users can write to log directories.
• Replace affected uutils `tail` usage with a fixed version or a validated non-vulnerable `tail` implementation until upstream fixes are deployed.
• Search scripts, service definitions, cron jobs, shell histories, and automation repositories for `tail --follow=name` and `tail -F` usage against writable paths.
• Harden log directory permissions so untrusted users cannot replace monitored file names with symlinks.
• Enable audit logging for symlink creation and file replacement in sensitive log directories where feasible.
• Review historical logs, terminal capture systems, service outputs, and log aggregation stores for accidental disclosure of sensitive files such as `/etc/shadow`, private keys, tokens, and application secrets.
• If sensitive file contents are found in logs or output streams, treat the affected secrets as compromised: rotate credentials, replace keys, and remove exposed data from retained logs where policy permits.