uutils coreutils CVE-2026-35368

Exploitation requires the attacker to have write access to the directory specified as NEWROOT in the chroot command, which is a non-default insecure configuration. Specifically, the NEWROOT directory (or subdirectories where NSS modules are loaded, typically /lib or /lib64) must be writable by the low-privileged attacker before the chroot command executes. The chroot utility must be invoked with the --userspec option to trigger getpwnam() user resolution. The target system must use glibc as its C library implementation, as the vulnerability depends on glibc's Name Service Switch dynamic module loading behavior. Attack is limited to local access (AV:L) and requires the attacker to already have low-privilege local credentials (PR:L). High attack complexity (AC:H) reflects the need for write access to the chroot target, timing the file placement before chroot execution, and knowledge of the correct NSS module path conventions. These conditions are unlikely in properly configured container environments where chroot directories are administrator-controlled read-only filesystems, but may exist in development environments, shared build systems, or misconfigured multi-tenant platforms where users can write to directories later used as chroot targets.

Real-world risk assessment reveals multiple limiting factors despite the high CVSS score. The CVSS vector (AV:L/AC:H/PR:L) indicates local access with high attack complexity and low privileges required, not remote exploitation. Attack complexity is high because exploitation requires the attacker to have both local access and write permissions to the NEWROOT directory being used as the chroot target-a configuration that violates basic container security principles where chroot directories should be administrator-controlled and read-only. SSVC framework confirms POC exists (exploitation: poc) and total technical impact, but critically notes the attack is not automatable, requiring specific environmental conditions. The Scope Changed metric is the most concerning aspect, indicating container escape potential where this affects containerized workloads using uutils coreutils. However, adoption of uutils coreutils versus standard GNU coreutils remains limited primarily to Rust-centric environments, significantly reducing attack surface. No EPSS score or KEV status provided-absence from CISA KEV despite POC availability suggests no widespread exploitation observed. Primary risk exists in containerized build environments or multi-tenant systems where users can write to directories that later become chroot targets, which represents a deployment anti-pattern. Organizations using standard GNU coreutils or properly configured immutable container images face no risk.

An attacker with low-level local access to a build server or multi-tenant container platform identifies a container build process that uses uutils coreutils chroot with --userspec to create isolated environments. The attacker discovers they have write access to a shared /tmp directory that becomes the NEWROOT during container creation. Before the build process executes 'chroot --userspec user:group /tmp/container_root /bin/sh', the attacker places a malicious libnss_files.so.2 library in /tmp/container_root/lib/x86_64-linux-gnu/ containing a constructor function with arbitrary shellcode. When chroot executes with --userspec, getpwnam() triggers NSS to load the attacker's malicious library with root privileges before privilege dropping occurs, executing the injected code as root and granting full system access or container escape. Publicly available POC code exists demonstrating the injection technique.