CVE-2026-35367

What it actually does

The uutils coreutils implementation of nohup creates the default output file nohup.out without explicitly setting restrictive file permissions. As a result, the file is created according to the caller's umask, commonly producing mode 0644, which is readable by other local users. In multi-user systems, stdout and stderr captured from background commands may therefore be exposed to unauthorized local users. The issue is local, requires an existing user account on the same host, and impacts confidentiality only; it does not directly permit code execution, privilege escalation, data modification, or service disruption.

Why it matters to the business

Sensitive command output may be unintentionally exposed on shared systems, including tokens, credentials, file paths, job results, logs, customer data fragments, or operational details printed by scripts. The practical risk is highest on multi-user Linux/Unix environments, build servers, shared development hosts, HPC systems, bastion hosts, and automation runners where multiple users can read files in another user's working directory. The currently low EPSS, lack of known exploitation maturity, and absence from CISA KEV indicate low broad exploitation pressure, but the weakness is easy for a local user to abuse opportunistically once present.

How an attack unfolds

An attacker first obtains or already has low-privileged local access to a system where uutils coreutils provides the nohup utility. The attacker identifies directories used by other users to launch long-running commands with nohup, such as home directories, project workspaces, shared build directories, or temporary working directories. When a target user runs a command with nohup and does not redirect output explicitly, uutils creates nohup.out using umask-derived permissions, often world-readable. The attacker then reads the file directly if filesystem permissions allow access to the directory and file. Any sensitive stdout or stderr content captured in nohup.out can be harvested without modifying the target process or escalating privileges.

How to fix it

Upgrade uutils coreutils to a version that creates nohup.out with owner-only permissions equivalent to GNU coreutils behavior, when a fixed release is available from the project or operating-system package maintainers. No fixed version was provided in the input, so track upstream uutils coreutils advisories and distribution security updates. As an immediate mitigation, avoid relying on the default nohup.out file: explicitly redirect stdout and stderr to files created with restrictive permissions, for example after setting umask 077. Administrators can also enforce safer shell profiles or wrapper scripts that set umask 077 before running nohup, and can periodically correct existing nohup.out files with chmod 600 where appropriate. On shared systems, review directory permissions as well; even a world-readable file is less exposed if parent directories are not traversable by other users.

How to confirm the fix worked

Confirm the installed nohup implementation and package source, then test behavior in a non-production or temporary directory. Set a permissive umask such as 022, run a harmless command with nohup without explicit redirection, and inspect the resulting nohup.out permissions. A vulnerable behavior produces a file readable by group or other users, commonly -rw-r--r--. A corrected implementation should create nohup.out with owner-only permissions, typically -rw-------, regardless of umask. Also scan existing filesystems for nohup.out files with group or world read bits set and verify that mitigations or upgrades prevent newly created files from inheriting unsafe permissions.

Typical attack path

1. Gain low-privileged local access to a multi-user host.
2. Determine that the installed nohup is from uutils coreutils or otherwise behaves with umask-derived permissions for nohup.out.
3. Search accessible user, project, build, or temporary directories for nohup.out files.
4. Check file permissions for world-readable or group-readable nohup.out files, such as mode 0644 or 0640 with a shared group.
5. Read captured stdout/stderr from accessible nohup.out files.
6. Extract sensitive values such as credentials, tokens, command output, internal URLs, job logs, or operational data.
7. Use any recovered secrets or information for follow-on access, lateral movement, or data collection.

How to detect it

To determine whether the issue was already exploited, focus on evidence of unauthorized reads of nohup.out files. Useful sources include Linux auditd file access logs, EDR file telemetry, shell history, process accounting, sudo/session logs, terminal recording systems, and filesystem metadata. Look for users opening, reading, copying, grepping, tailing, or archiving nohup.out files owned by other users. Pay special attention to reads from home directories, build workspaces, shared project directories, and temporary directories. If auditd was not configured to record reads, forensic confirmation may be limited; use file access times only cautiously because atime may be disabled, relatime may reduce precision, and legitimate owner reads can overwrite evidence. Review the contents of exposed nohup.out files for secrets or sensitive data and rotate any credentials, tokens, or keys that may have been printed there.

• nohup.out
• -rw-r--r--
• -rw-r-----
• cat nohup.out
• less nohup.out
• more nohup.out
• tail nohup.out
• tail -f nohup.out
• grep nohup.out
• strings nohup.out
• cp nohup.out
• scp *nohup.out*
• rsync *nohup.out*
• tar *nohup.out*
• find / -name nohup.out
• find . -name nohup.out
• find / -name nohup.out -perm -004
• find / -name nohup.out -perm -040
• ausearch -f nohup.out
• type=PATH msg= audit
• name="nohup.out"
• comm="cat"
• comm="less"
• comm="more"
• comm="tail"
• comm="grep"
• comm="cp"

What your security team should do

• Inventory systems using uutils coreutils, especially shared Linux/Unix hosts, development systems, build runners, HPC clusters, and bastion-style servers.
• Prioritize remediation on systems with multiple local users or shared project directories, even though internet-scale exploitation likelihood is low.
• Track upstream and distribution package updates for uutils coreutils and deploy the first release that explicitly restricts nohup.out permissions.
• Until patched, enforce umask 077 for users and automation that may run nohup, or require explicit redirection to pre-created 0600 log files.
• Search for existing nohup.out files with group/world read permissions and review them for exposed secrets before changing permissions or deleting them.
• Add detections for non-owner reads of nohup.out on shared systems where file access auditing is available.
• Educate developers and operators not to print secrets to stdout/stderr and not to rely on default nohup.out handling for sensitive jobs.