CVE-2026-35368

What it actually does

The flaw is a local privilege escalation in uutils coreutils chroot when the --userspec option is used on glibc-based systems. The utility enters the requested NEWROOT while still running with root privileges, then resolves the supplied user name using getpwnam() before dropping privileges. On glibc, that lookup can invoke Name Service Switch behavior and load libnss_*.so.2 shared objects from paths inside the new root. If an attacker can write to the NEWROOT filesystem, they can place a malicious NSS library or configuration there and have code executed as root in the chroot process context. In containerized use cases, this can support privilege escalation and potentially container escape depending on runtime configuration, mounts, capabilities, and host exposure.

Why it matters to the business

Successful exploitation can turn limited local or container-level access into root-level code execution, which can lead to host compromise, unauthorized access to sensitive data, service disruption, tampering with workloads, and lateral movement. The public exploitation signal is currently low, with low EPSS and no known KEV listing or ransomware association, but the impact is severe where automation, build systems, container entrypoints, CI jobs, or administrative scripts invoke uutils chroot with --userspec against attacker-writable roots.

How an attack unfolds

An attacker first obtains low-privileged local access or control over files inside a directory that will be used as the chroot NEWROOT. They prepare that directory so glibc NSS resolution inside the chroot will consult attacker-controlled files and attempt to load an attacker-controlled NSS shared library. An administrator, script, container runtime helper, build tool, or automation task then invokes the vulnerable uutils chroot with --userspec using a user name rather than a safely pre-resolved numeric identity. The vulnerable program enters the chroot while still privileged and calls getpwnam() to resolve the user. During that lookup, glibc may load NSS modules from the chrooted filesystem. The attacker's library code runs before privileges are dropped, giving the attacker root-level execution in the process context and potentially enabling broader host or container escape actions depending on surrounding isolation controls.

How to fix it

Upgrade uutils coreutils to a version that fixes the --userspec privilege-dropping order once an official fixed version is available from the project or operating-system/package maintainer. No exact fixed version was provided in the input, so rely on vendor advisories and package manager security metadata. Until patched, avoid using uutils chroot --userspec where NEWROOT is writable by untrusted users. Prefer numeric UID:GID values that are resolved before entering the chroot, or use tooling that drops privileges before performing name-service lookups. Ensure chroot root directories are owned by root, not writable by untrusted users, and mounted read-only where possible. In container and CI/CD environments, remove unnecessary write access to chroot roots, avoid running chroot helpers with elevated capabilities, and consider using the distro GNU coreutils chroot or another hardened implementation if confirmed unaffected by this issue. Harden NSS behavior inside chroot images by reviewing /etc/nsswitch.conf and preventing untrusted placement of libnss_*.so.2 files under lib directories.

How to confirm the fix worked

Confirm whether installed chroot comes from uutils coreutils and whether the installed package version is vulnerable according to vendor advisories. Inventory scripts, service units, build jobs, container entrypoints, and administrative automation for use of chroot with --userspec. Confirm that any NEWROOT passed to chroot is not writable by untrusted users and does not contain unexpected libnss_*.so.2 files or NSS configuration. On glibc systems, perform lab-only validation with tracing tools such as strace or auditd to verify whether chroot --userspec attempts to open NSS configuration or load libnss modules from inside the NEWROOT before dropping privileges. After remediation, validate that updated binaries no longer perform attacker-controlled NSS lookups while privileged, or that the risky invocation pattern has been removed.

Typical attack path

1. Gain local low-privileged access or write access to a directory that will be used as a chroot NEWROOT.
2. Identify a workflow that runs uutils coreutils chroot with the --userspec option against that writable NEWROOT.
3. Place attacker-controlled NSS-related configuration and libnss_*.so.2 shared objects inside the NEWROOT filesystem.
4. Wait for or trigger the privileged chroot invocation using a user-name-based --userspec value.
5. During getpwnam() user resolution, cause glibc NSS to load the attacker-controlled module from inside the chroot.
6. Execute code with root privileges before the chroot process drops privileges.
7. Use the elevated execution context to alter files, gain persistence, access secrets, or attempt container/host escape depending on available mounts and capabilities.

How to detect it

Look for evidence of privileged chroot executions using --userspec, especially where the target root directory was writable by non-root users. Useful log sources include Linux auditd execve records, process accounting, EDR process telemetry, shell history on administrative accounts, sudo logs, CI/CD job logs, container runtime logs, file integrity monitoring, and package manager logs. Investigate unexpected creation or modification of NSS-related files inside chroot roots, including /etc/nsswitch.conf and libnss_*.so.2 under lib or lib64 paths. Review audit or EDR file events showing chroot opening or mapping libnss modules from a NEWROOT path immediately before privilege changes. Suspicious artifacts include newly compiled shared objects, unusual ownership or timestamps on NSS modules, temporary build artifacts near chroot roots, and privileged processes spawned as descendants of chroot. If exploitation is suspected, preserve the NEWROOT filesystem, collect hashes and metadata for NSS libraries, inspect shared objects for malicious exports or embedded command strings, and correlate the timing with root-level process creation, file writes, or container escape attempts.

• chroot --userspec
• /usr/bin/chroot --userspec
• /bin/chroot --userspec
• --userspec=
• libnss_*.so.2
• /etc/nsswitch.conf
• /lib/libnss_
• /lib64/libnss_
• /usr/lib/libnss_
• /usr/lib64/libnss_
• /lib/x86_64-linux-gnu/libnss_
• /usr/lib/x86_64-linux-gnu/libnss_
• openat.*libnss_.*\.so\.2
• mmap.*libnss_.*\.so\.2
• execve.*chroot.*--userspec
• type=EXECVE.*chroot.*--userspec
• getpwnam
• nsswitch.conf

What your security team should do

• Inventory all Linux systems, container images, CI runners, build hosts, and administrative scripts that include uutils coreutils and use chroot with --userspec.
• Prioritize remediation on shared hosts, container platforms, CI/CD infrastructure, build systems, and environments where untrusted users can write to directories later used as chroot roots.
• Patch uutils coreutils as soon as a vendor-fixed version is available; where no fixed version is available, replace or disable vulnerable chroot usage.
• Block or refactor workflows that run chroot --userspec against attacker-writable NEWROOT directories.
• Enforce ownership and permissions so chroot roots are root-owned and not writable by untrusted users; use read-only mounts where practical.
• Monitor for suspicious libnss_*.so.2 files, modified /etc/nsswitch.conf files, and privileged chroot executions using --userspec.
• Review container runtime profiles, Linux capabilities, bind mounts, and host filesystem exposure to limit the blast radius of any root execution inside a chroot or container.
• Because public exploitation indicators are currently low but impact is high, treat internet-scale emergency patching as lower priority than targeted remediation of exposed multi-user and containerized environments.