CVE-2026-35371

What it actually does

The flaw is a local, low-severity integrity issue in the `id` utility from uutils coreutils. When a process has different real and effective user IDs, the utility’s pretty-printed output performs the effective-user name lookup using the effective group ID instead of the effective user ID. This does not directly grant privileges, read data, or execute code, but it can produce incorrect identity information. Scripts, operational checks, or administrators that rely on this output may make wrong authorization, ownership, or permissions decisions.

Why it matters to the business

Organizations using uutils coreutils could receive misleading user identity information during administrative checks or automation workflows. The main risk is incorrect operational decision-making, such as misdiagnosing privilege context or applying file permission changes based on wrong output. The likelihood of broad exploitation is low: the issue requires local access, has a low CVSS score, very low and flat EPSS, no known exploit maturity, and is not listed in CISA KEV or associated with ransomware campaigns.

How an attack unfolds

An attacker would first need local access to a system where uutils coreutils is installed and where the `id` command is used in workflows involving differing real and effective UIDs, such as setuid-style execution contexts or privilege-transition checks. The attacker could then trigger or influence a situation where `id` pretty-print output is consulted by an administrator or automation. Because the utility may display the wrong effective user name, the attacker’s goal would be to cause a human or script to make an incorrect permissions or access-control decision. This is a manipulation-of-output scenario rather than a direct compromise primitive; successful abuse depends heavily on local context and downstream trust in `id` output.

How to fix it

Upgrade uutils coreutils to a version that contains the corrected `id` implementation once a fixed version is available from the project, operating system distribution, package manager, or downstream vendor. No fixed versions were provided in the input, so track vendor advisories and package release notes for the exact remediation version. As a mitigation, avoid using affected `id` pretty-print output as an authoritative source for security decisions when real and effective UIDs may differ. Prefer numeric UID/GID checks or independently verified system calls in scripts, and review automation that parses `id` output for authorization, ownership, or permission logic.

How to confirm the fix worked

Confirm the installed coreutils implementation is uutils coreutils rather than GNU coreutils or another implementation. Check the package version against vendor advisories once a fixed release is published. Functionally validate by testing `id` behavior in a controlled context where the real UID and effective UID differ, and confirm that the displayed effective user name corresponds to the effective UID rather than the effective GID. Review scripts and administrative tooling for parsing of `id` pretty-print output, especially where decisions are made based on effective user identity.

Typical attack path

1. Gain local user-level access to a system using uutils coreutils.
2. Identify scripts, administrative procedures, or troubleshooting steps that rely on `id` pretty-printed output to determine effective identity.
3. Create or wait for an execution context where the real UID and effective UID differ.
4. Run or cause execution of the affected `id` utility in that context.
5. Leverage the misleading effective-user display to influence a permissions, ownership, or access-control decision.
6. Benefit from the resulting misconfiguration or incorrect operational action, if one occurs.

How to detect it

There are no known threat actors, KEV activity, ransomware usage, or public exploit maturity associated with this issue. Because exploitation would primarily involve local misuse of misleading command output, there may be no unique forensic artifact that distinguishes malicious use from normal administration. To investigate possible prior abuse, review shell history, process execution telemetry, EDR logs, auditd logs, sudo logs, and automation logs for `id` execution in workflows where real and effective UIDs differ. Correlate those executions with subsequent ownership, permission, ACL, or access-control changes, especially commands such as `chmod`, `chown`, `setfacl`, user/group management changes, or deployment scripts that parse `id` output. Focus on evidence of incorrect permission changes rather than the mere presence of the `id` command, which is commonly benign.

What your security team should do

• Inventory systems and containers using uutils coreutils, with priority on administrative hosts, build environments, minimal container images, and systems that run privilege-transition scripts.
• Monitor vendor and upstream uutils coreutils advisories for the fixed release, since no fixed version is currently specified.
• Treat this as a low-urgency integrity issue unless local automation relies on `id` output for access-control or permission changes.
• Refactor scripts to use numeric UID/GID values or direct, trusted APIs instead of parsing human-readable `id` output.
• Add regression tests for automation that runs under differing real and effective UIDs.
• Do not prioritize emergency response solely for this CVE: EPSS is very low and stable, no public exploit maturity is indicated, and it is not in CISA KEV.