Sudo local privilege escalation – CVE-2025-32463

What is Sudo :-

Sudo is a command-line application in Unix-like operating systems that enables a low-privilege user to run a command as another user, usually the root/administrator user.

The tool effectively grants temporary higher rights without the user having to log in as root.

The user must authenticate themself using their password, and if allowed by the configuration file (usually /etc/sudoers), the system will run the requested command.

Sudo chroot Introduction

The chroot command alters a process’s root directory, allowing it to only see and access files in a given folder. For example, an SFTP or FTP server can utilize chroot to lock each user into their own home folder, preventing them from accessing other portions of the system. However, chroot does not provide robust security because it just alters the visible file paths and does not entirely secure or isolate the process, making it feasible to escape if not properly configured. Sudo also includes a chroot option (-R or –chroot) for running commands in a separate root directory, but this is rarely used and reserved for exceptional scenarios. Containers or virtual machines provide better isolation.

CVE-2025-32463 Description:-

CVE-2025-32463 is a critical vulnerability in Sudo’s chroot option that allows a local user to escalate privileges and potentially gain root access to the underlying system. The flaw was introduced in Sudo version 1.9.14 when the command matching logic was updated to improve how paths are handled when the -R (--chroot) option is used. According to Sudo’s maintainers, this option is meant to let a user run commands within a custom root directory, but only if the sudoers policy explicitly allows it. However, the updated logic now performs a chroot() to the user-specified directory before fully evaluating the sudoers file, which means the environment can be manipulated at a critical stage.

The vulnerability arises because an unprivileged user can point Sudo’s chroot() to a writable, untrusted path under their control. This path can contain a crafted /etc/nsswitch.conf file — a configuration file that tells the system how to resolve information about users, groups, and hosts. Between Sudo’s internal pivot_root() and unpivot_root() operations (defined in plugins/sudoers/pivot.c), the system’s Name Service Switch (NSS) will read this untrusted configuration and may load arbitrary shared libraries specified by the attacker. This behavior is particularly dangerous because other secure applications, such as SSH, explicitly prevent chroot() to any directory that is not owned by root to avoid this exact type of abuse. In this case, the flawed implementation lets a local attacker leverage a writable chroot target to execute code as root on systems that use /etc/nsswitch.conf for name resolutio

Impact:

• Privilege Escalation: A local, low-privileged user can gain root access by abusing the --chroot option.
• Arbitrary Code Execution: By creating a fake /etc/nsswitch.conf inside a writable chroot path, the attacker can trick the system into loading malicious shared libraries.
• Bypasses Intended Restrictions: Even if the sudoers file does not fully permit chroot use, the flawed logic performs chroot() during path checks, exposing the system.

Mitigation

• To correct the chroot path handling logic, immediately update Sudo to the current patched version (see to the official Sudo release notes or your Linux distro’s security advisory).
• Restrict sudo rules by auditing your sudoers file and removing unneeded –chroot (-R) commands. Untrusted users should not be allowed to perform commands with chroot access.
• Use root-owned chroot directories only: If you must use chroot, make sure the target directories are owned by root and not writable by non-privileged users.
• Consider Disabling the Feature: If you don’t use sudo -R for valid reasons, consider turning it off to reduce the attack surface.

POC

Exploit Link: Click me

git clone https://github.com/kh4sh3i/CVE-2025-32463.git
cd CVE-2025-32463
chmod +x exploit.sh
id
./exploit.sh
id