One CVE this week strikes at a tool present on nearly every Linux and Unix-like system in production anywhere: a bug in sudo itself, the very mechanism organizations rely on to grant controlled, limited privileged access, that instead let local users bypass sudoers rules entirely and run arbitrary commands as root.
CVE-2025-32463 — Sudo Inclusion of Functionality from Untrusted Control Sphere Vulnerability — CVSS 9.3 (Critical), added to CISA's KEV catalogue on 29 September 2025.
Why a bug in the access-control tool itself is a different category of problem
Sudo exists for exactly one purpose: to let organizations grant specific users specific privileged commands without handing out full root access indiscriminately. The entire security model of a well-run Linux fleet depends on sudo enforcing the rules written into /etc/sudoers faithfully — a user listed for one narrow command should never be able to parlay that into full root. NVD's description states plainly that this vulnerability allows local users to obtain root access "because /etc/nsswitch.conf from a user-controlled directory is used with the --chroot option," affecting sudo before 1.9.17p1. CISA's own summary makes the scope of the failure explicit: an attacker could leverage sudo's -R (--chroot) option to run arbitrary commands as root "even if they are not listed in the sudoers file" — meaning this bypasses the access-control model entirely, not merely exceeds an over-permissive grant. A user with zero sudo entitlements at all could still reach full root.
The mechanism is a classic untrusted-search-path problem (CWE-829, inclusion of functionality from an untrusted control sphere): sudo's chroot option changes the root directory context for a command, and in doing so, it ends up trusting a nsswitch.conf file from a location the invoking user controls rather than one under the system administrator's control. Nsswitch.conf governs how the system resolves names and services — a file an attacker controls in this position can redirect that resolution process toward attacker-supplied logic, and because sudo runs with root privileges by design, whatever it trusts in that context runs with root privileges too.
Why this deserves attention beyond its raw CVSS number
A 9.3 score already places this among the more severe findings covered in this series, but the number understates how operationally significant this particular class of bug is. Local privilege escalation vulnerabilities are frequently treated as lower priority than remote code execution bugs, on the reasoning that an attacker needs local access first. That reasoning breaks down for exactly the population of systems where sudo matters most: multi-user servers, shared development and build infrastructure, and any environment where an organization deliberately grants a broad set of users limited local access precisely because sudo is trusted to enforce the boundary between "limited access" and "root." A bug that lets any local user — not just one already holding some sudo entitlement — reach root defeats the entire reason many organizations chose to grant local access as liberally as they did in the first place. The CVSS vector reflects this: local access vector, low complexity, no privileges required, no user interaction — the lowest possible bar for an attacker who already has any account on the box at all.
Sudo's ubiquity compounds the exposure. It ships by default across essentially every major Linux distribution and is present on macOS and many BSD systems as well, meaning the affected-version question ("is this system running sudo before 1.9.17p1") applies across a workstation fleet, server fleet, and container base-image inventory simultaneously — not a narrow enterprise product with a bounded install base.
What to check this week
Inventory sudo package versions across every Linux, macOS, and Unix-like system in the environment, treating this as a fleet-wide check rather than a server-only concern — sudo before 1.9.17p1 is the affected range regardless of what role a given machine plays.
Prioritize patching on any multi-user or shared-access system first, since the exploit path requires local access an attacker already needs some foothold to obtain — systems where multiple people or automated processes already hold local accounts are the highest-value targets for this specific bug.
Check container base images and golden VM images for the affected sudo version, since a vulnerable version baked into a widely-used image template propagates the exposure to every instance built from it, often invisibly to a per-host patch audit.
Review sudoers configurations generally as part of this remediation, since this incident is a reminder that the access-control boundary sudo enforces is only as strong as sudo's own code — a periodic review of who holds any local access at all, independent of their sudoers entitlements, is a reasonable companion step.
A final consideration on trusting the trust mechanism
Every layered security model has a component that everything else depends on being correct — for Unix-like systems, sudo is one of the more consequential examples, since it is the boundary between "has an account" and "has root." A confirmed-exploited bug in that specific boundary component deserves faster remediation than its CVSS score alone might suggest, precisely because every other access-control assumption built on top of "sudo enforces the rules correctly" was quietly wrong for any system still running an affected version.
How Safeguard helps
Safeguard's continuous inventory tracks exact package versions like sudo across the full Linux and Unix-like fleet — workstations, servers, and the container and VM images they were built from — surfacing every instance still running a version before 1.9.17p1 so a foundational access-control bug like CVE-2025-32463 gets the fleet-wide, version-specific remediation it requires rather than a spot-check limited to whichever systems happened to prompt the review.
