CVE-2026-35368: uutils coreutils Privilege Escalation

CVE-2026-35368 Overview

A privilege escalation vulnerability exists in the chroot utility of uutils coreutils when using the --userspec option. The vulnerability stems from improper sequencing of operations where the utility resolves user specifications via getpwnam() after entering the chroot environment but before dropping root privileges. On glibc-based systems, this behavior can trigger the Name Service Switch (NSS) to load shared libraries (e.g., libnss_*.so.2) from the new root directory. If the NEWROOT directory is writable by an attacker, they can inject a malicious NSS module to execute arbitrary code as root, facilitating a full container escape or privilege escalation.

Critical Impact

Attackers with write access to the chroot NEWROOT directory can achieve full root privilege escalation or container escape by injecting malicious NSS shared libraries that execute arbitrary code before privileges are dropped.

Affected Products

• uutils coreutils (versions using the vulnerable chroot implementation with --userspec option)
• glibc-based Linux systems utilizing NSS for name resolution

Discovery Timeline

• April 22, 2026 - CVE-2026-35368 published to NVD
• April 22, 2026 - Last updated in NVD database

Technical Details for CVE-2026-35368

Vulnerability Analysis

This vulnerability is classified as CWE-426 (Untrusted Search Path), which occurs when an application searches for critical resources using an externally-supplied search path that can point to resources controlled by malicious actors.

The core issue lies in the timing and sequence of privilege-sensitive operations within the chroot utility. When the --userspec option is provided, the utility must resolve the specified user and group information. However, this resolution occurs after the process has already changed its root directory to NEWROOT but before it has relinquished its root privileges.

On glibc-based systems, the getpwnam() function call initiates NSS lookups, which dynamically loads shared libraries from paths relative to the current root directory. Since the chroot has already been executed, the NSS subsystem searches for modules like libnss_files.so.2, libnss_compat.so.2, or other configured NSS backends within the attacker-controlled NEWROOT.

Root Cause

The vulnerability originates from a Time-of-Check Time-of-Use (TOCTOU) design flaw combined with an untrusted search path issue. The chroot utility enters the new root environment before completing all privileged operations that require loading external resources. The glibc NSS mechanism, designed to be modular and configurable, becomes a vector for code execution when the library search path falls within attacker-controlled territory.

Specifically, the problematic sequence is:

1. The chroot() system call changes the root directory to NEWROOT
2. The utility calls getpwnam() to resolve the user specification
3. NSS loads libnss_*.so.2 modules from the new root's library paths
4. Only then does the utility drop privileges via setuid()/setgid()

This ordering allows malicious code in injected NSS modules to execute with full root privileges.

Attack Vector

This is a local attack vector requiring the attacker to have write access to the NEWROOT directory that will be used with the chroot command. The attack unfolds as follows:

1. The attacker identifies or creates a directory that will be used as NEWROOT for a privileged chroot invocation
2. The attacker creates the appropriate library directory structure (typically /lib/ or /lib64/) within NEWROOT
3. A malicious shared library is placed in this path, named to match an NSS module (e.g., libnss_files.so.2)
4. When a privileged user or automated process executes chroot --userspec=<user>:<group> NEWROOT ..., the malicious library is loaded and executed with root privileges

The attack is particularly dangerous in containerized environments where the NEWROOT may be constructed from untrusted sources or where build processes operate within chroot environments.

For technical details and the ongoing discussion, see the GitHub Issue Discussion.

Detection Methods for CVE-2026-35368

Indicators of Compromise

• Unexpected or modified NSS shared libraries (libnss_*.so.2) appearing in chroot target directories
• Suspicious shared library files in non-standard locations within container or chroot environments
• Evidence of privilege escalation following chroot operations in system logs
• Anomalous process execution chains originating from chroot invocations

Detection Strategies

• Monitor for creation or modification of libnss_*.so.2 files in directories used as chroot targets
• Implement file integrity monitoring (FIM) on directories commonly used as chroot NEWROOT paths
• Audit system calls to detect chroot() followed by suspicious library loads using tools like auditd or eBPF-based monitoring
• Deploy runtime protection that detects library injection attempts during privileged operations

Monitoring Recommendations

• Enable detailed logging for all chroot command executions with user context
• Configure security tooling to alert on shared library creation in temporary or build directories
• Implement container security scanning to detect suspicious library configurations in container images
• Monitor for unexpected dlopen() calls within processes that have recently executed chroot()

How to Mitigate CVE-2026-35368

Immediate Actions Required

• Audit all systems using uutils coreutils chroot with the --userspec option
• Ensure NEWROOT directories are not writable by unprivileged users before chroot operations
• Consider switching to GNU coreutils chroot if a patched version of uutils coreutils is not available
• Review and restrict permissions on container build environments and chroot target directories

Patch Information

Users should monitor the uutils coreutils GitHub repository for updates regarding this vulnerability. A proper fix would involve resolving user specifications before entering the chroot environment or implementing safeguards to prevent NSS module loading from untrusted paths.

Workarounds

• Avoid using the --userspec option with chroot when the NEWROOT is potentially attacker-controlled
• Pre-resolve user and group IDs and use numeric UID/GID specifications instead of names when possible
• Ensure NEWROOT directories and their library subdirectories are owned by root with restrictive permissions (e.g., chmod 755)
• Use mount namespaces or other isolation mechanisms to prevent library injection attacks

# Configuration example - Restrict NEWROOT directory permissions before chroot
# Ensure the target directory is owned by root and not writable by others
chown -R root:root /path/to/newroot
chmod -R go-w /path/to/newroot

# Alternatively, use numeric UID:GID instead of usernames to avoid getpwnam()
chroot /path/to/newroot /bin/sh -c "exec setpriv --reuid=1000 --regid=1000 --init-groups /application"