CVE-2025-32463

What it actually does

This is a local privilege escalation vulnerability in sudo versions before 1.9.17p1. When sudo is invoked with the chroot option, it can resolve Name Service Switch configuration from an attacker-controlled chroot directory rather than the trusted system configuration. A local user can place a crafted /etc/nsswitch.conf and supporting NSS library content inside a directory they control, then cause sudo to load attacker-controlled NSS functionality while sudo is running with elevated privileges. Successful exploitation results in code execution as root on the local system.

Why it matters to the business

A user or process with local access to an affected Linux or Unix-like host can become root, giving them full control of the system. This can turn a low-privileged shell, compromised service account, developer account, or foothold from another vulnerability into complete host compromise. Because this vulnerability is in CISA KEV, has active in-the-wild exploitation, and has a high EPSS score, organizations should treat exposed systems as urgent patching priorities, especially shared servers, build systems, bastion hosts, appliances, and internet-facing systems where attackers may first gain limited access. CISA-listed environments should remediate by 2025-10-20.

How an attack unfolds

An attacker first needs local code execution or a valid low-privileged account on a vulnerable host. They create a directory tree that mimics parts of a root filesystem, including an attacker-controlled etc/nsswitch.conf. The malicious NSS configuration references an attacker-controlled NSS module or lookup behavior located inside that directory tree. The attacker then invokes sudo with the chroot option pointing at the controlled directory. Vulnerable sudo versions consult the untrusted nsswitch.conf while operating with elevated privileges, causing attacker-controlled NSS code or behavior to execute in the sudo context. The attacker then obtains a root shell, installs persistence, tampers with logs, accesses secrets, or pivots further. Public exploitation has been reported in active campaigns, so suspicious local sudo chroot usage should be investigated as potentially malicious rather than treated as ordinary administration.

How to fix it

Upgrade sudo to version 1.9.17p1 or later, or apply the vendor-provided security update that backports the fix. For source-based deployments, ensure the sudo-project/sudo fix including commit 84e7ca6752a2d3a32452adee177d1f57421dd814 is present. For Mageia 7 packaging listed in the input, update to the fixed package version 1.9.4-1.mga7 or later as provided by the distribution. Because downstream vendors often backport security patches without changing to the upstream version number, validate using the vendor advisory and package changelog, not only the displayed sudo version. If immediate patching is not possible, restrict local shell access, remove unnecessary sudo access, monitor and block unusual sudo use with --chroot or -R where operationally feasible, and prioritize compensating controls on multi-user systems and systems exposed to untrusted workloads. Do not rely on sudoers policy alone as a complete mitigation if vulnerable sudo binaries remain installed.

How to confirm the fix worked

Confirm the installed sudo package is fixed using the operating system package manager and vendor advisory metadata. Run sudo -V and compare the reported version and package release against the vendor-fixed version; upstream builds should be 1.9.17p1 or later. On source builds, confirm the code includes commit 84e7ca6752a2d3a32452adee177d1f57421dd814 or a later equivalent fix. Search fleet inventory for sudo versions earlier than 1.9.17p1 and for vendor packages lacking the relevant security advisory. Validate that sudo chroot invocation no longer loads NSS configuration from a user-controlled chroot tree. Review endpoint and audit logs for historical sudo executions containing --chroot or -R arguments, especially by non-administrative users, service accounts, web server users, CI/CD users, or accounts that do not normally perform system administration.

Typical attack path

1. Gain local access to a vulnerable Linux or Unix-like system through stolen credentials, a compromised service, SSH access, web shell, container escape path, or another vulnerability.
2. Check whether sudo is present and whether its version is earlier than 1.9.17p1 or an unfixed vendor backport.
3. Create a user-controlled directory containing a crafted etc/nsswitch.conf file.
4. Place attacker-controlled NSS-related files or libraries in the chroot directory structure so they can be resolved by sudo.
5. Run sudo with the chroot option, such as --chroot or -R, pointing to the attacker-controlled directory.
6. Trigger sudo to load or consult the untrusted NSS configuration while running with elevated privileges.
7. Execute commands as root and use that access to disable defenses, collect credentials, modify system files, install persistence, or move laterally.

How to detect it

Investigate whether this was already exploited by correlating process execution logs, Linux auditd records, sudo logs, shell history, EDR telemetry, and filesystem artifacts. Focus on sudo executions containing --chroot or -R, especially when the chroot target is under user-writable locations such as /tmp, /var/tmp, /dev/shm, home directories, web application directories, or CI workspaces. In auditd, look for execve events where the executable is sudo and arguments include --chroot or -R. In sudo logs, look for COMMAND entries showing chroot usage or unusual command execution by accounts that do not normally administer systems. On disk, search for chroot-like directory structures containing etc/nsswitch.conf and suspicious libnss_*.so files outside normal system library paths. Review file creation and modification times around suspicious sudo events. Because successful exploitation provides root access, also hunt for post-exploitation activity: new setuid binaries, modified sudoers files, added SSH keys, unexpected systemd services, cron persistence, new root-owned files in temporary paths, cleared logs, unusual outbound connections, credential dumping, and security tooling tampering. Threat intelligence reports active exploitation of this vulnerability, so any matching artifact should trigger host-level incident response and not only routine patch validation.

• sudo --chroot
• sudo -R
• COMMAND=.*sudo.*--chroot
• COMMAND=.*sudo.* -R
• EXECVE.*sudo.*--chroot
• EXECVE.*sudo.* -R
• /etc/nsswitch.conf
• etc/nsswitch.conf
• libnss_*.so
• /tmp/*/etc/nsswitch.conf
• /var/tmp/*/etc/nsswitch.conf
• /dev/shm/*/etc/nsswitch.conf
• /home/*/etc/nsswitch.conf
• /tmp/*/lib*/libnss_*.so
• /var/tmp/*/lib*/libnss_*.so
• /dev/shm/*/lib*/libnss_*.so
• /home/*/lib*/libnss_*.so
• sudo: .*COMMAND=.*--chroot
• sudo: .*COMMAND=.* -R

What your security team should do

• Patch or upgrade sudo on all affected systems immediately, prioritizing internet-facing hosts, bastion hosts, CI/CD infrastructure, multi-user servers, developer workstations, and systems where untrusted users or workloads have shell access.
• For CISA KEV compliance programs, track remediation against the 2025-10-20 due date and treat missed remediation as a high-risk exception.
• Run fleet-wide discovery for sudo versions before 1.9.17p1 and for vendor package releases that do not include the backported fix.
• Hunt for suspicious sudo executions using --chroot or -R, especially from non-admin users or from directories under /tmp, /var/tmp, /dev/shm, home directories, web roots, or build workspaces.
• Search filesystems for unexpected user-writable chroot-like trees containing etc/nsswitch.conf and libnss_*.so files.
• If exploitation is suspected, preserve audit logs, shell histories, sudo logs, EDR telemetry, and filesystem timestamps before remediation.
• Review root-level persistence mechanisms on suspected systems, including cron jobs, systemd units, SSH authorized_keys, PAM changes, sudoers modifications, shell profile changes, and unexpected setuid binaries.
• Reduce unnecessary local access and sudo privileges, particularly for service accounts, application users, and shared development accounts.
• Create SIEM detections for sudo invocations with chroot arguments and for creation or execution of libnss_*.so from user-writable paths.
• After patching, rotate credentials and secrets stored on systems where exploitation is plausible, because successful exploitation grants full host access.