Two Sudo Vulnerabilities Discovered and Patched

In April researchers responsibly disclosed two security flaws found in Sudo "that could enable local attackers to escalate their privileges to root on susceptible machines," reports The Hacker News. "The vulnerabilities have been addressed in Sudo version 1.9.17p1 released late last month." Stratascale researcher Rich Mirch, who is credited with discovering and reporting the flaws, said CVE-2025-32462 has managed to slip through the cracks for over 12 years. It is rooted in the Sudo's "-h" (host) option that makes it possible to list a user's sudo privileges for a different host. The feature was enabled in September 2013. However, the identified bug made it possible to execute any command allowed by the remote host to be run on the local machine as well when running the Sudo command with the host option referencing an unrelated remote host. "This primarily affects sites that use a common sudoers file that is distributed to multiple machines," Sudo project maintainer Todd C. Miller said in an advisory. "Sites that use LDAP-based sudoers (including SSSD) are similarly impacted."

CVE-2025-32463, on the other hand, leverages Sudo's "-R" (chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file. It's also a critical-severity flaw. "The default Sudo configuration is vulnerable," Mirch said. "Although the vulnerability involves the Sudo chroot feature, it does not require any Sudo rules to be defined for the user. As a result, any local unprivileged user could potentially escalate privileges to root if a vulnerable version is installed...."

Miller said the chroot option will be removed completely from a future release of Sudo and that supporting a user-specified root directory is "error-prone."

XKCD classic

[Slashythenkilly]

Sudo Go make me a sandwich

When will sudo read email?

[TuballoyThunder]

There is so much complexity incorporated into sudo that it may well be past the tipping point of perpetual vulnerabilities.

Re:

[bjoast]

The host bug seems completely bizarre. I haven't read the code, but from the article it appears to me as a bolted on feature. I can't imagine any proper design work ever having taken place when this was implemented. I don't trust sudo, and for that reason I have a separate user for operations requiring privilege escalation.

Re:

[fuzzyfuzzyfungus]

I can't comment on where sudo itself lives on the spectrum from aggressively solid implementation to really-dodgy-smell-around-the-edges; but it seems like its purpose is a fundamentally tricky problem even if its execution were impeccable.

The basic "user is authorized for root; but we'd prefer he be thinking and logged when he uses that authorization" is reasonably cogent use case; but it's more of a reminder than a security barrier. Then you get into the actually-interesting attempts at limited delegat

Re:

[bjoast]

Yes, configuring sudo correctly, when granular command-level privileges are required, demands an understanding of the command you are allowing a user to execute. It's very easy to insert an unintended privilege escalation point. As you mention, the general problem is not really solvable within the domain of sudo. Often, the correct solution when command-level access rights for administrators is the objective, is to develop an administration interface, be it a web application or an interactive shell, where a

I don't see what the big deal is

[rsilvergun]

I mean if these were real vulnerabilities sure but these are sudo.

Weird

[Artem S. Tashkinov]

I posted this four days ago when it was pertinent and relevant:

https://slashdot.org/submissio... [slashdot.org]

my submission was never approved and now most distros have already released a fix.

Re:

[thegarbz]

I wouldn't take it personally. Slashdot gets a lot of submissions, most of them rubbish, many of them multiple at a time. Yours probably didn't even get read.

sudo-rs

[CommunityMember]

The alternative implementation, sudo-rs, written in rust to be memory safe, is not vulnerable to these bugs, but that is because it choose not to implement those particular (not commonly used) features. There may be something about cleaning up code that has benefits. Who would have thought?

Re:

[Uecker]

It would have been much more useful to clean up the code that is widely deployed.