In the world of Linux privilege management, Sudo reigns supreme. It’s the gatekeeper, the doorman, the bouncer of root-level access. But what happens when the bouncer hands over the keys to anyone who knows a clever trick?
According to a new security advisory from Rich Mirch at Stratascale’s Cyber Research Unit (CRU), two critical vulnerabilities in Sudo—CVE-2025-32463 and CVE-2025-32462—do exactly that. These flaws, quietly sitting in the world’s most trusted command elevation tool, allow attackers to bypass configuration safeguards and escalate privileges to root, even when they’re explicitly denied such access.
CVE-2025-32463 (CVSS Score: 9.3) – Chrooted but Not Contained
Affected Versions: Sudo 1.9.14 to 1.9.17 inclusive
Sometimes, the walls we build to protect us become the doorways that let attackers in. That’s the story behind CVE-2025-32463—a local privilege escalation bug that abuses Sudo’s rarely used –chroot (-R) option.
“An attacker can leverage sudo’s -R (–chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file,” the advisory warns.
The root of the problem (pun intended) lies in how Sudo implemented chroot() starting with version 1.9.14. The tool started resolving paths within the chroot environment before evaluating the sudoers file. This meant an attacker could trick Sudo into reading a fake /etc/nsswitch.conf file—one that instructs it to load malicious shared libraries like libnss_/woot1337.so.2.
The result? Arbitrary code execution as root, with no sudoers permissions.
CRU’s proof-of-concept (sudo-chwoot.sh) drives the point home:
Just like that—lowpriv becomes highpriv.
To fix the issue, Sudo 1.9.17p1 reverts the changes made in version 1.9.14 and deprecates the –chroot feature entirely. The patch removes the pivot_root() logic, making it impossible to call chroot() during command matching.
CVE-2025-32462 (CVSS Score: 2.8) – The Host You Can’t Trust
Affected Versions: Sudo 1.8.8 to 1.9.17 inclusive
While less flashy than its chroot cousin, CVE-2025-32462 is no less dangerous—especially in enterprise environments where centralized sudoers files span multiple hosts.
Designed to allow users to list their privileges on a different host, the –host (-h) option was never meant to be used for executing commands. But thanks to a 12-year-old logic oversight, it could be.
“The bug effectively makes the hostname portion of a sudoers rule irrelevant since the user can set the host to be used when evaluating the rules themselves,” CRU explains.
Take this real-world example from the advisory:
This rule should allow Alice to run commands only on the host cerebus. But with the flaw, Alice can run those same commands on any host, just by adding -h cerebus to her sudo command—even if she’s explicitly denied access on the current machine.
The fix? As of Sudo 1.9.17p1, the –host option is finally limited to its original purpose: listing rules. Attempting to use it for other operations now triggers a usage error, as it always should have.
In both cases, attackers can escalate privileges without needing to modify the sudoers file or gain admin approval.
“Because of this behavior, any local user can trick Sudo into loading an arbitrary shared object, resulting in arbitrary code execution as root,” the advisory summarizes.
Related Posts:
- Sudo Releases Patch for Double Free Vulnerability (CVE-2023-27320)
- Microsoft released the PowerShell Core that support MacOS/Linux OS
- CVE-2024-22036 (CVSS 9.1): Critical RCE Vulnerability Discovered in SUSE Rancher
- Major npm flaw crashes Linux Systems, force users to reinstall
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.