We provide security updates only for the latest released version of uutils/coreutils. Older versions may not receive patches. If you are using a version packaged by your Linux distribution, please check with your distribution maintainers for their update policy.

uutils/coreutils is a set of local command-line utilities. There is no network-facing service, so remote vulnerabilities do not apply. When assessing whether a report is a security issue, we focus on whether it crosses a trust or privilege boundary on the local system.

In scope (treated as security issues):

• Privilege-boundary violations - bypassing a documented safety guard (e.g. --preserve-root), acting on files outside the intended scope, or privilege escalation in setuid/sudo contexts.
• Filesystem race conditions - TOCTOU bugs, symlink following, and unsafe directory traversal in utilities that recurse or operate on paths (cp, mv, rm, chown, chmod, install, …). TOCTOU (Time-Of-Check to Time-Of-Use) is when a utility checks a file's state (existence, type, permissions) and then acts on it in a separate step, leaving a window for an attacker to swap the path in between - e.g. replacing a regular file with a symlink so the action lands on a different target. Safe traversal is the defense: when walking a directory tree, descend with symlink-aware primitives (openat/O_NOFOLLOW, file descriptors instead of re-resolved paths) so a symlink swapped in mid-walk cannot redirect the operation outside the intended tree.
• Unintended destructive actions - operations that delete, overwrite, or signal something the user did not ask for, where the input that triggers it reaches the utility across a trust boundary: an attacker-supplied filename or file content that a privileged script, cron job, or automated pipeline processes. A divergence from GNU makes such a bug real and worth fixing, but it is the boundary crossing that makes it a security issue - see "What makes a report a vulnerability" below.
• Memory-safety issues, integer overflow, or unbounded allocation reachable from untrusted input.

Out of scope (report as a normal bug, not a security issue):

• Crashes, panics, or incorrect output with no privilege or safety impact.
• Cosmetic differences from GNU (messages, exit-code-only mismatches) that do not change which files or processes are affected.
• Issues requiring an already-privileged or already-malicious local actor who could achieve the same effect directly.
• A divergence from GNU on its own. Differing from GNU - including failing where GNU errors, or erroring where GNU succeeds - is a bug we want reported, but it is not by itself a vulnerability. The question is what the divergence lets an attacker do that they could not do already. For example: an argument-parsing difference that makes a utility treat an attacker-chosen filename as an option is a real bug, but if the result stays inside the caller's own permissions and the operands the caller already named, no boundary was crossed - it belongs in a public issue.
• Data loss or a destructive action with no boundary crossing - a utility destroying the caller's own files, under the caller's own permissions, from the caller's own arguments.
• An absent or ineffective mitigation that grants no access. A control that fails open leaves the user where they would have been without it. That is a bug to fix promptly, not an advisory, unless the failure itself hands someone access they did not have.
• Availability bounded to the caller's own job - a hang, an unbounded loop, or resource use that affects only the invocation that asked for it (see below).

One test decides it: name the attacker and what they gain.

• Who is the attacker? If the only party in the reproduction is the operator running their own command in their own environment, there is no boundary and no vulnerability. What could happen in a hypothetical hostile deployment does not supply one.
• What do they control? Inputs - a filename, file contents, a directory a privileged process walks, the environment a caller passes in. Not the privileged process's own code, arguments, or configuration.
• What do they end up with that they did not have before? If the end state gives them no access, no privilege, and no reach beyond what they already had
  • if it is merely less of something the operator wanted - it is a bug.

If you cannot answer all three, please open a normal public issue instead. That is not a lesser outcome: it gets the bug fixed faster, in the open, and you are credited the same way. Declining an advisory is never declining the fix - if we judge a report to be a bug rather than a vulnerability, we will say so plainly, file it publicly, credit you, and fix it.

If you are unsure, report it privately anyway. We would much rather triage a borderline report than miss a real one.

Because these are local tools, resource exhaustion (hang, infinite loop, unbounded memory/CPU, crash on crafted input) is only a security issue when the triggering input crosses a trust boundary. A user who runs a utility on their own data and exhausts their own resources is harming only their own invocation - that is a normal bug. It is in scope when crafted, untrusted input reaches the utility through a boundary the victim does not control, such as a privileged script, a cron job, or an automated pipeline that processes attacker-influenced filenames or file contents and is thereby wedged, blocked, or terminated.

Severity reflects impact, not just whether a bug exists: a guard bypass that can hit the whole filesystem is critical, while a local availability issue bounded by the caller's existing permissions is low.

Do not open public GitHub issues for security vulnerabilities. This prevents accidental disclosure before a fix is available.

Please use one of the following methods:

• GitHub (preferred): open a private report at https://github.com/uutils/coreutils/security/advisories/new ("Report a vulnerability").
• Email: sylvestre@debian.org
• Encryption (optional): You may encrypt your report using our PGP key: Fingerprint: B60D B599 4D39 BEC4 D1A9 5CCF 7E65 28DA 752F 1BE1

To help us investigate and resolve the issue quickly, please include as much detail as possible:

• Type of issue: e.g. privilege escalation, information disclosure.
• Location in the source: file path, commit hash, branch, or tag.
• Steps to reproduce: exact commands, test cases, or scripts.
• Special configuration: any flags, environment variables, or system setup required.
• Affected systems: OS/distribution and version(s) where the issue occurs.
• Impact: your assessment of the potential severity (DoS, RCE, data leak, etc.).

We follow a Coordinated Vulnerability Disclosure (CVD) process:

1. We will acknowledge receipt of your report within 10 days.
2. We will investigate, reproduce, and assess the issue.
3. We will provide a timeline for developing and releasing a fix.
4. Once a fix is available, we will publish a GitHub Security Advisory.
5. You will be credited in the advisory unless you request anonymity.