CVE-2026-35370

What it actually does

The affected uutils coreutils implementation of the `id` utility calculates the `groups=` portion of its output using the user's real group ID instead of the effective group ID. In contexts where real and effective GIDs differ, such as setgid execution, privilege transitions, wrappers, or automation running under altered credentials, `id` can report group membership differently from GNU coreutils. If scripts, policy checks, installers, deployment jobs, or access-control logic trust this output to decide whether a user has a required group, the incorrect result can cause authorization decisions to be made on the wrong identity context. The flaw requires local privileges and does not directly provide remote code execution, but it can enable unauthorized access or incorrect permission assignment when vulnerable output is used in security-sensitive automation.

Why it matters to the business

Organizations using uutils coreutils in place of GNU coreutils may have automation that makes access decisions using incorrect group information. The practical risk is that users or processes could be granted access they should not have, denied access they should have, or cause systems to be configured with incorrect permissions. The CVSS score is moderate and EPSS is very low with no observed upward trend, no known CISA KEV listing, and no reported exploit maturity, so broad opportunistic exploitation is unlikely; however, the issue matters in environments where scripts rely on `id` output for authorization, deployment gates, or privilege checks.

How an attack unfolds

An attacker with local access identifies a host or execution path using uutils coreutils where scripts invoke `id` and parse the `groups=` field to make a security decision. The attacker then runs or influences that script from a context where the real GID and effective GID differ. Because the vulnerable `id` implementation derives group membership from the real GID instead of the effective GID, the script may receive misleading group information. If the script treats that output as authoritative, it may incorrectly approve an operation, apply an insecure permission set, skip a required restriction, or grant access to a resource. Exploitation is therefore highly dependent on local automation design and requires a vulnerable trust relationship between `id` output and access-control logic.

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 or operating-system package maintainer. No fixed version was provided in the input, so track vendor advisories and package repositories for the first patched release. Where immediate upgrade is not possible, replace vulnerable `id` usage with GNU coreutils `id` on affected systems, or modify security-sensitive scripts so they do not rely on parsing `id` output for authorization. Prefer direct OS APIs, well-reviewed library calls, explicit effective-ID checks, or policy engines that distinguish real, effective, and supplementary groups. Audit setgid and privilege-transition paths that call `id`, and ensure access decisions are based on the intended identity context. Treat scripts parsing `id | grep`, `id -a`, or `groups=` as candidates for review.

How to confirm the fix worked

Confirm whether systems are using uutils coreutils by checking package metadata and the behavior/version of the installed `id` binary. Validate remediation by testing `id` in a controlled scenario where real and effective GIDs intentionally differ and confirming that the `groups=` output reflects the correct effective-GID-based behavior expected from the fixed implementation or from GNU coreutils. Review application, deployment, and administrative scripts for parsing of `id` output, especially the `groups=` field. After patching or replacing the binary, rerun regression tests for access-control and permission-management workflows that previously depended on `id`. If no fixed package is available, document compensating controls and verify that security-sensitive automation no longer uses vulnerable output for authorization decisions.

Typical attack path

1. Gain local access to a system that uses uutils coreutils rather than GNU coreutils.
2. Identify scripts, wrappers, service hooks, installers, CI jobs, or administrative tooling that call `id` and parse the `groups=` output.
3. Find an execution context where the real GID and effective GID differ, such as a setgid helper, privilege-transition wrapper, or controlled automation path.
4. Trigger the vulnerable `id` behavior so the group list is computed from the wrong GID context.
5. Cause the consuming script or process to make an incorrect authorization or permission decision.
6. Use the resulting misconfiguration or authorization bypass to access data, perform an operation, or persist permissions that should not have been granted.

How to detect it

There are no universal network indicators or malware artifacts for this vulnerability because exploitation depends on local scripts trusting incorrect `id` output. To assess whether it was already abused, review shell history, auditd logs, sudo logs, CI/CD job logs, systemd service logs, and script execution logs for suspicious or unexpected invocations of `id` in privileged, setgid, deployment, or administrative contexts. Focus on commands that parse `groups=` or compare group membership before granting access or changing permissions. Review file permission, ownership, and ACL changes made by automation after such invocations, especially changes that granted broader access than expected. If auditd or process accounting is available, correlate executions of `id` with processes whose real and effective GIDs differ. Examine custom scripts, cron jobs, service hooks, package install scripts, and build/deployment pipelines for evidence that access-control decisions were made from vulnerable output. Since there are no known threat actors, KEV listing, ransomware usage, or public exploit maturity reported for this CVE, detection should be behavior- and environment-specific rather than IOC-driven.

What your security team should do

• Inventory Linux/Unix-like systems and container images that use uutils coreutils, especially minimal distributions, Rust-based userlands, embedded environments, and custom images.
• Prioritize review of systems where local users, CI jobs, build agents, service accounts, or administrative scripts rely on `id` output for authorization or permission decisions.
• Track the uutils coreutils upstream and distribution advisories for a patched release, then upgrade as soon as it is available.
• Replace vulnerable `id` usage with GNU coreutils `id` or safer direct identity/group checks in security-sensitive automation until a patch is deployed.
• Search code repositories and scripts for parsing of `groups=` or command invocations of `id` used in access-control decisions.
• Test setgid, sudo-like, wrapper, and privilege-transition workflows for mismatches between real and effective GID behavior.
• Because EPSS is low, there is no KEV listing, and exploit maturity is currently none, prioritize based on local exposure and reliance on affected automation rather than emergency internet-wide scanning.