Overview

A critical local privilege escalation vulnerability, CVE-2025-32463, was discovered in sudo versions 1.9.14 through 1.9.17. The flaw allows a local, unprivileged user to obtain full root access by abusing the --chroot option during sudo execution. The vulnerability arises from sudo loading system configuration files from a user-controlled directory while still operating with root privileges. By carefully crafting a fake filesystem hierarchy, an attacker can force sudo to load a malicious shared library and execute arbitrary code as root. This issue was discovered and responsibly disclosed by Rich Mirch of the Stratascale Cyber Research Unit in June 2025. It has been assigned a CVSS v3.1 score of 9.3 (Critical).

Affected Versions

The following sudo versions are vulnerable:

• 1.9.14
• 1.9.15
• 1.9.16
• 1.9.17

Most major Linux distributions shipped affected versions, including Ubuntu, Debian, Red Hat, SUSE, and Kali Linux.

Why This Vulnerability Matters

Sudo is one of the most security-critical binaries on Linux systems. It is trusted to safely mediate privilege boundaries between unprivileged users and the root account. CVE-2025-32463 breaks that trust. The vulnerability allows privilege escalation without sudoers permissions, root access without authentication, exploitation by any local user, and complete system compromise. Any system running a vulnerable sudo version should be considered fully compromised once exploited.

What Is Sudo and the chroot Option

Sudo allows permitted users to execute commands as root based on rules defined in the sudoers file. The -R or --chroot option is intended to run a command with an alternative root directory, mimic a limited filesystem view, and support testing or sandbox-style workflows. In simple terms, it lets sudo pretend that a user-specified directory is /.

Root Cause of CVE-2025-32463

In sudo 1.9.14, a change was introduced that altered how path resolution worked when using --chroot. Sudo began resolving files using chroot() before the sudoers policy evaluation had completed. This meant sudo was still running as root, the filesystem root was now user-controlled, and critical configuration files were loaded from attacker-controlled paths.

How the Exploit Works (High-Level)

The exploit follows a straightforward logic chain.

First, the attacker prepares a fake root directory, typically under /tmp, containing a fake /etc/nsswitch.conf and a malicious libnss_*.so shared library. This directory mimics a minimal Linux filesystem layout.

Next, the attacker abuses name service switching. The nsswitch.conf file controls how Linux resolves users, groups, and other identity-related lookups. By modifying this file, the attacker instructs sudo to load a custom NSS module from the fake root directory.

Then, the attacker invokes sudo with the --chroot option pointing to the prepared directory. Because sudo is still running as root and resolves NSS libraries before policy enforcement, it loads the attacker-controlled shared object with root privileges.

Finally, the malicious library executes automatically when loaded. Typical payload behavior includes setting UID and GID to 0, spawning a root shell, or executing arbitrary commands. At this point, the attacker has full root access.

Why sudoers Does Not Protect You Here

A critical aspect of this vulnerability is that sudoers permissions are irrelevant. The exploit occurs before sudoers enforcement, during library loading, while sudo is already running as root. Even users with no sudo access can escalate privileges.

Impact

Successful exploitation allows a local attacker to gain unrestricted root access, execute arbitrary commands, install persistent backdoors, disable security controls, and fully compromise the operating system. The vulnerability requires no user interaction and no special permissions.

Remediation and Mitigation

Official Fix

The vulnerability was fixed in sudo 1.9.17p1. The fix reverts the unsafe chroot behavior, deprecates the --chroot feature, and prevents loading configuration from user-controlled roots.

Recommended Actions

System administrators should upgrade sudo to version 1.9.17p1 or later, apply vendor-provided security patches immediately, audit systems for local user access, and review use of the --chroot feature.

Temporary Mitigation

If immediate patching is not possible, disable chroot functionality by adding "Defaults !use_chroot" to sudoers. This reduces exposure but does not replace patching.

Final Thoughts

CVE-2025-32463 demonstrates how subtle changes in execution order can undermine foundational security guarantees. A single design decision allowed user-controlled files to influence root-level execution. The result was complete privilege escalation on systems that rely on sudo for access control. Organizations should treat this vulnerability as a reminder that privilege boundaries must be enforced early, configuration loading is part of the attack surface, and local vulnerabilities can be just as devastating as remote ones. If you run a vulnerable sudo version, patching is not optional.

‍

References

1. MongoDB Official Security Update (December 2025)
2. NIST National Vulnerability Database (NVD) Entry for CVE-2025-14847

‍