How to Fix CVE-2025-32463 (Sudo Chroot Privilege Escalation, USN-7604-1)

CVE-2025-32463 is a local privilege escalation in sudo 1.9.14 through 1.9.17: any local user can abuse the -R (--chroot) option to make sudo load a malicious library and run commands as root, even without a sudoers entry. Fix it by upgrading sudo to 1.9.17p1 or your distribution’s patched package, such as USN-7604-1 on Ubuntu.

What the scanner is actually detecting

Nessus reports this under a different plugin for each distribution. All of them are local checks, so they only appear in credentialed (SSH) scans, and Tenable states for each one that Nessus did not test the flaw but relied on the package’s self-reported version number.

The Ubuntu, SUSE and Gentoo plugins bundle two separate sudo bugs fixed in the same upstream release:

• CVE-2025-32463 (chroot option). A change in sudo 1.9.14 made sudo resolve paths inside the user-supplied chroot directory while it was still evaluating the sudoers policy. An attacker creates an /etc/nsswitch.conf under a directory they control, and sudo loads an arbitrary shared library from it as root. Affected: 1.9.14 to 1.9.17 inclusive.
• CVE-2025-32462 (host option). The -h (--host) option was meant only for listing privileges with -l, but sudo also accepted it when running a command. A user could therefore pick which host’s rules applied to them. Affected: 1.8.8 to 1.9.17 inclusive.

Ubuntu 22.04 LTS ships sudo 1.9.9, which predates the chroot change, so USN-7604-1 lists only CVE-2025-32462 for 22.04. The chroot bug applies to 24.04 LTS, 24.10 and 25.04.

Real-world risk

Both are local privilege escalations. An attacker needs to run commands on the host first. After that, the two bugs are very different in practice.

• CVE-2025-32463 is the serious one. The sudo project states the attacker does not need to be listed in the sudoers file. Stratascale, who reported it, says the default sudo configuration is vulnerable and confirmed it on Ubuntu 24.04.1 and Fedora 41 Server. Tenable notes a public Metasploit module, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on September 29, 2025, with a federal due date of October 20, 2025.
• CVE-2025-32462 needs a specific setup. The user must already be in sudoers, and the rules must name a host other than ALL. That usually means one sudoers file shared across many machines, or sudoers rules stored in LDAP or SSSD. Without host-restricted rules, there is nothing to bypass.

Severity numbers vary by source. NVD rates CVE-2025-32463 at 7.8 (CVSS v3.1), while the CVE assigner rated it 9.3. For CVE-2025-32462 the split runs the other way: NVD says 8.8, the assigner 2.8. Tenable’s 8.8 score for plugin 241066 comes from that NVD rating for the host bug. For prioritization, the chroot bug matters more: it is exploited in the wild and works on a default install. Shell servers, jump hosts, CI runners and any host running an exposed service account should go first.

How to confirm it on the host

Check the installed package and the version sudo reports:

# Debian, Ubuntu (also shows sudo-ldap and libnss-sudo if present)
dpkg -l | grep -i sudo

# SUSE, RHEL, Azure Linux, CBL-Mariner
rpm -q sudo

# Any platform: upstream version string
sudo -V | head -n 1

A version below 1.9.14 is outside the chroot bug’s range, although the host bug may still apply. Distribution packages backport fixes without changing the upstream number, so a patched Ubuntu 24.04 host still reports 1.9.15p5. Check the package changelog for the CVE IDs:

# Debian, Ubuntu
zgrep -E 'CVE-2025-3246(2|3)' /usr/share/doc/sudo/changelog.Debian.gz

# RPM-based distributions
rpm -q --changelog sudo | grep -E 'CVE-2025-3246(2|3)'

Then look for legitimate chroot use, which Stratascale recommends reviewing. Commands run through sudo’s chroot feature are logged with a CHROOT= string:

sudo grep -rnE 'CHROOT=|runchroot' /etc/sudoers /etc/sudoers.d/
sudo journalctl _COMM=sudo | grep 'CHROOT='

If sudoers rules come from LDAP, query the directory for the same keywords. For CVE-2025-32462, look for rules whose host field is not ALL, for example alice cerebus = ALL, especially in files pushed by configuration management.

How to fix it

There is no configuration workaround. The sudo project fixed both bugs in 1.9.17p1, and Red Hat states no mitigation meets its criteria. Install the patched package for your platform:

The sudo-ldap package gets the same fixed version as sudo on each Ubuntu release. Any later package from the same repository also contains the fix.

Ubuntu and Debian

sudo apt update
sudo apt install --only-upgrade sudo
dpkg -l | grep -i sudo

The Nessus solution names sudo, sudo-ldap and libnss-sudo. If the dpkg output shows either of the other two installed, upgrade them in the same way.

SUSE and openSUSE

sudo zypper refresh
sudo zypper update sudo
rpm -q sudo

The SUSE plugin also lists subpackages such as sudo-devel and sudo-plugin-python. Update whichever of them rpm -qa 'sudo*' shows.

Gentoo

emerge --sync
emerge --ask --oneshot --verbose ">=app-admin/sudo-1.9.17_p1"

RHEL 10, Azure Linux and CBL-Mariner

# RHEL 10
sudo dnf update sudo

# Azure Linux 3.0, CBL-Mariner 2.0
sudo tdnf update sudo

Source-built sudo

A sudo compiled from source (often in /usr/local/bin) is invisible to the package manager and to distribution plugins. Rebuild from 1.9.17p1 or later, and run which -a sudo to make sure no older copy sits earlier in the PATH.

Clean up chroot rules

Upstream has deprecated the chroot feature and plans to remove it in a future release. Remove runchroot= and CHROOT= entries you found earlier, then validate with sudo visudo -c. This is housekeeping, not a mitigation: the exploit needs no sudoers rule, so removing chroot rules does not protect an unpatched host.

How to verify the fix and rescan

1. Compare dpkg -l or rpm -q sudo output with the table above, or rerun the changelog grep and confirm both CVE IDs appear.
2. On source builds, confirm sudo -V | head -n 1 reports 1.9.17p1 or later.
3. Rerun the credentialed Nessus scan. Check the Nessus Scan Information output (plugin 19506) to confirm credentialed checks show yes. If the SSH login failed, local plugins do not run and the finding disappears for the wrong reason. Our guide to Linux authenticated scanning over SSH covers the account and privilege settings.

sudo is not a daemon, so no service restart or reboot is needed. Each new invocation runs the updated binary.

What can break and how to roll back

• Scripts that pass -h with a command. After the fix, -h (--host) is accepted only with -l. Anything that ran commands with sudo -h somehost ... worked only because of the bug and will now fail.
• Locally edited sudoers files. dpkg may prompt about a changed configuration file during an interactive upgrade, and RPM can leave a .rpmnew copy. Run sudo visudo -c afterwards.
• Losing privileged access. Keep a root shell or console session open while updating sudo on remote hosts.

To roll back, reinstall the previous version if your mirror still has it:

# Ubuntu, Debian
sudo apt install sudo=<previous-version>

# RHEL 10
sudo dnf history list sudo
sudo dnf history undo <transaction-id>

# SUSE
sudo zypper install --oldpackage sudo-<previous-version>

A rollback reintroduces a vulnerability on the KEV list, so do it only long enough to fix whatever broke.

Common false positive reasons

• Backported fixes. Patched Ubuntu 24.04 and SUSE packages still report 1.9.15p5, and the patched RHEL 10 package is labelled 1.9.15. A generic check that compares only the upstream number against 1.9.17p1 will flag them. If the changelog lists the CVE and the package matches the advisory, the host is fixed. See why backported patches cause scanner false positives for how to document it.
• Versions older than 1.9.14. Red Hat states CVE-2025-32463 does not affect RHEL 9 or earlier. A chroot finding on those systems is a mismatch, but check CVE-2025-32462 separately.
• Ubuntu 22.04 flagged by 241066. This is not a false positive. The title names both CVEs, but on 22.04 only the host bug applies. The update is still required.
• Stale or uncredentialed results. The report predates the update, or the rescan ran without working SSH credentials.

FAQ

Does an attacker need sudo rights to exploit CVE-2025-32463?

No. The sudo project states it works even if the user is not listed in sudoers. Any local account on an affected version is enough.

Does removing CHROOT rules from sudoers fix it?

No. The exploit does not depend on any chroot rule being present. Only the patched package closes it.

Is Ubuntu 22.04 affected by the chroot bug?

No. Its sudo 1.9.9 predates the 1.9.14 change. USN-7604-1 still fixes CVE-2025-32462 there.

Do I need to reboot after updating sudo?

No. The next sudo invocation uses the new binary.

Tracking this finding across many hosts

On a large Linux fleet, the hard part is proving every host is closed. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export and supports per-finding retest for Nessus, so each host can be rechecked after patching. Its AI can draft host-specific remediation scripts that run only after human approval, deployed by SITEY agents on Linux endpoints, followed by a retest to verify closure.

Sources

• sudo project: Local Privilege Escalation via chroot option (CVE-2025-32463)
• sudo project: Local Privilege Escalation via host option (CVE-2025-32462)
• Ubuntu: USN-7604-1 Sudo vulnerabilities
• Tenable: Nessus plugin 241066
• Tenable: CVE-2025-32463