CVE-2026-35371: Logical Identity Spoofing in uutils coreutils id Utility

The uutils/coreutils project is a cross-platform, Rust-based implementation of the traditional GNU coreutils software suite. This package serves as an alternative to the original GNU suite written in C, aiming to offer memory-safety guarantees inherent to the Rust programming language. One of the utilities provided by this package is the id binary. The id command is used across POSIX-compliant operating systems to print real and effective user and group information for a process. Under normal conditions, the utility translates numeric identification values into string representations by querying system database mappings.\n\nThis utility exposes an attack surface when operating in multi-user systems, privilege separation layers, or during local execution context changes. Specifically, the vulnerability categorized under CVE-2026-35371 manifests as a logical validation flaw (CWE-451). This flaw occurs during the execution of the pretty-print formatting flow of the id utility when there is a mismatch between the process's real User ID (UID) and its effective User ID (EUID). Such mismatches commonly occur when a binary utilizes the setuid permission bit or is executed through administrative tools such as setpriv or sudo configuration states.\n\nInstead of evaluating the effective user name using the effective User ID, the code base uses the effective Group ID (EGID) to execute the lookup. This leads to a scenario where the utility prints a spoofed or misleading username as the active EUID. The breakdown in state display does not directly compromise memory but creates a vector of identity misrepresentation, which directly affects downstream scripts and administrative parsing suites that rely on the formatted output of the id command.\n\nBecause the underlying numeric types for user IDs and group IDs map to the same primitive integer types in Rust wrappers, the compiler does not flag the parameter swap during compilation. This mismatch remains silent until the utility runs in an environment where the effective Group ID has been configured to match the numeric User ID of a different system account. This creates conditions where an unprivileged local user can display a false effective identity to administrative tools.

The fundamental issue driving CVE-2026-35371 lies within how Unix-like operating systems manage process credentials and how standard utilities perform reverse-lookups. On POSIX systems, a running process tracks several distinct identities, including the real User ID (RUID), real Group ID (RGID), effective User ID (EUID), and effective Group ID (EGID). The kernel uses the effective credentials (EUID and EGID) to evaluate authorization policies during system calls, file access operations, and socket interactions. The real IDs represent the user who originally instantiated the process, whereas the effective IDs represent the context under which active authorization occurs.\n\nWhen a tool like id executes, it performs a system database lookup to translate numeric identifiers (such as UID 1000 or GID 1000) to corresponding human-readable strings (such as 'alice' or 'staff'). These lookups typically wrap libc calls such as getpwuid (for user names) and getgrgid (for group names). Under the Rust Standard Library and external dependency libraries like the nix crate, these functions are exposed via standard wrapper APIs. The underlying types for both user IDs and group IDs are defined as libc::uid_t and libc::gid_t, which are aliases to the primitive unsigned 32-bit integer type u32.\n\nBecause of this common type representation, Rust's type-safety mechanisms do not differentiate between user identifiers and group identifiers at the API boundary unless explicitly wrapped in custom types. In the source file src/uu/id/src/id.rs, a variable-mismatch logic bug was introduced during development. The program correctly retrieves the effective Group ID (EGID) and the effective User ID (EUID), but when resolving the effective user name string, it mistakenly supplies the EGID variable as the input argument to the user lookup function uid2usr.\n\nIf the EGID matches a valid numeric UID of a different user on the host system, the name resolution query succeeds and retrieves the username corresponding to that UID. For example, if a process runs with an EUID of 3000 (user 'bob') and an EGID of 2000 (group 'developers'), and a separate user account 'alice' exists with UID 2000, the id utility queries the database for UID 2000 and incorrectly reports 'alice' as the effective user name. This mismatch bypasses logical expectations and misrepresents active process privileges.

To understand the structure of the logic flaw, it is necessary to examine the vulnerable implementation in src/uu/id/src/id.rs. The code pattern below illustrates how variables were extracted and passed to the resolution functions prior to the fix:\n\nrust\n// Vulnerable logic inside uutils/coreutils id.rs\nfn print_pretty(uid: uid_t, gid: gid_t, euid: uid_t, egid: gid_t) {\n // Retrieve normal user and group representations\n let username = uid2usr(uid);\n let groupname = gid2grp(gid);\n\n // ERROR: Passing effective GID (egid) to the user lookup function (uid2usr)\n // Because both egid and euid are u32 primitives, the compiler does not flag this.\n let effective_user = uid2usr(egid as uid_t);\n\n println!(\"login\\t{}\", username);\n println!(\"uid\\t{}\", uid);\n println!(\"euid\\t{}\", effective_user);\n println!(\"groups\\t{}\", groupname);\n}\n\n\nThe fix commit replaces the incorrect variable parameter with the intended variable euid. This modification restores correct behavior by mapping the effective user name directly to the effective user identifier:\n\nrust\n// Patched logic inside uutils/coreutils id.rs\nfn print_pretty(uid: uid_t, gid: gid_t, euid: uid_t, egid: gid_t) {\n // Retrieve normal user and group representations\n let username = uid2usr(uid);\n let groupname = gid2grp(gid);\n\n // FIXED: Correctly pass the euid variable to resolve the effective user name\n let effective_user = uid2usr(euid);\n\n println!(\"login\\t{}\", username);\n println!(\"uid\\t{}\", uid);\n println!(\"euid\\t{}\", effective_user);\n println!(\"groups\\t{}\", groupname);\n}\n\n\nWhile the fix is structurally complete for this specific code path, the underlying programming pattern remains a source of potential issues. Simply using uid_t and gid_t aliases as u32 variables prevents the Rust compiler from catching similar parameter swaps elsewhere in the system codebase. To achieve robust security, developers should consider defining distinct newtypes such as struct UserId(u32) and struct GroupId(u32) to enforce separation of these domains at compile time.\n\nAdditionally, auditing adjoining utilities in the uutils/coreutils repository is necessary to ensure that copy-pasted implementations do not contain equivalent parameter mismatches. Utilities such as whoami and groups perform similar name-to-ID translations and require validation to guarantee that their logical checks correctly parse current execution contexts under complex privileges.

The exploitation of CVE-2026-35371 relies on manipulating local process execution contexts to fool downstream relying parties. To execute this technique, an attacker must have local access with command execution capabilities. The primary target is typically a shell script or local management agent running with high privileges that evaluates execution context using the id utility and performs actions on behalf of the reported username.\n\nTo perform the exploit, the attacker must identify a target user account whose UID matches an EGID that the attacker can assume. For instance, if an administrative account exists with UID 2000 (e.g., 'backup_agent') and the attacker can run a command with an EGID of 2000, they can trigger the vulnerability. The attacker can use tools like setpriv to manually set the effective User ID to their own unprivileged UID (e.g., 3000) while setting the effective Group ID to 2000:\n\nbash\nsudo setpriv --euid 3000 --egid 2000 --clear-groups /path/to/vulnerable/id -p\n\n\nWhen this command runs, the vulnerable id binary resolves the username for the effective group ID (2000) instead of the effective user ID (3000). The output falsely indicates that the effective user is 'backup_agent'.\n\nmermaid\ngraph LR\n A[\"Attacker Process (EUID=3000, EGID=2000)\"] --> B[\"Execute Vulnerable id Utility\"]\n B --> C[\"Lookup mapping: uid2usr(EGID=2000)\"]\n C --> D[\"Incorrectly Output euid as 'backup_agent'\"]\n D --> E[\"Downstream Script parses Output\"]\n E --> F[\"Bypass Access Control Policy\"]\n\n\nIf an automated administrative script parses the output of id (for example, executing id -p and searching for the string 'backup_agent' to authorize file modifications), the script will mistakenly evaluate the attacker's context as authorized. This results in an arbitrary bypass of the script's access control check, granting access to protected administrative operations without the attacker actually possessing the corresponding UID.

The severity of CVE-2026-35371 is rated as Low, with a CVSS v3.1 base score of 3.3. The attack vector is strictly Local (AV:L), and execution complexity is Low (AC:L). Because it requires local shell access, it cannot be directly triggered from a remote network location without an auxiliary entry vector such as an exposed SSH service or a web application command-injection vulnerability.\n\nWhile the direct impact is classified as Low because the utility itself does not contain memory corruption vulnerabilities or execute arbitrary code, the indirect impact can be significant. The vulnerability violates the integrity of administrative tool diagnostic data. In environments where security boundaries depend on text processing of standard utilities, this logical misrepresentation breaks the underlying threat model.\n\nIf automated system management scripts or local security daemons parse the stdout of id to decide whether to permit administrative operations, the identity spoofing leads directly to unauthorized privileges or access bypasses. System administrators rely on the correct behavior of core command-line utilities to diagnose configurations, meaning a spoofed display can mislead troubleshooting personnel into making unsafe policy changes.\n\nThe Exploit Prediction Scoring System (EPSS) rating for this vulnerability is extremely low (0.00123), indicating that it is not currently utilized by known threat groups in widespread malware or ransomware campaigns. It remains a localized risk relevant to systems running specific administrative workflows built on top of Rust-based coreutils rewrites.

The primary remediation strategy is to update the uutils/coreutils package to the latest commit that addresses issue 10006. This update replaces the incorrect parameter egid with the correct parameter euid within the identity lookup code inside src/uu/id/src/id.rs to ensure proper user resolution under all process contexts.\n\nOn systems where an immediate package update is not feasible, administrators should configure their environment to use standard GNU coreutils instead of the Rust rewrite. This can be accomplished by verifying that the standard PATH environment variable prioritizes /usr/bin (containing the C-based GNU implementation) over any custom paths containing uutils binaries:\n\nbash\n# Verify which binary is in use\nwhich id\n# Ensure it does not point to a uutils installation\n\n\nFurthermore, developers of system automation scripts should adopt safe scripting practices. Scripts should avoid parsing the stdout of helper utilities for access control decisions. Instead, use built-in shell features or native system calls. In Bash scripts, checking the $EUID environment variable provides a safer mechanism for evaluating privilege context, as it queries the kernel directly rather than parsing textual tool output:\n\nbash\n# Safer check within system scripts\nif [ \"$EUID\" -ne 2000 ]; then\n echo \"Access Denied\"\n exit 1\nfi\n\n\nFinally, development teams working on system utility ports should implement architectural boundaries to prevent similar type-swapping errors. Enforcing strong typing for user and group identifiers via separate structures prevents parameter confusion at compile-time and eliminates this entire class of bugs.