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.