A Routine Tool Under the Microscope

Sudo is one of those command-line helpers that most Linux and Unix administrators install and forget. It lets anyone with the right entry in the /etc/sudoers file perform system tasks that normally need super-user rights, all while keeping a clear audit trail. The idea is simple: give staff just enough power to do their jobs without handing out the full keys to the castle. That plan hit a snag this month when researchers found two separate flaws that, in the worst case, let any user flip the switch and become root.

How the First Flaw Slipped Through for Years

The first issue, tracked as CVE-2025-32462 and carrying a modest severity score, stems from Sudo’s “-h” host flag. Added back in 2013, that flag is supposed to show you what you are allowed to run on another machine, which is handy in large server fleets that share a single sudoers file. Stratascale researcher Rich Mirch noticed that under certain setups the flag does more than list permissions. If a shared sudoers file contains rules for a completely different server, a clever attacker can pass those host details to Sudo on the local box and actually run the commands instead of merely reading about them.

Project maintainer Todd C. Miller explained that the bug is most dangerous in environments that copy one sudoers file to many computers or that rely on LDAP-based configurations. In those scenarios, the same entry that should apply only to, say, a database server, quietly works on a workstation as well — a loophole that sat unnoticed for over a decade.

A Bigger Problem Hides in the Chroot Flag

The second weakness, CVE-2025-32463, is the headline act with a critical CVSS score of 9.3. It involves the “-R” flag, which tells Sudo to treat a directory as if it were the root of the file system, a feature often used for testing. During that process Sudo looks for /etc/nsswitch.conf to decide how to resolve user and group names. Mirch discovered that nothing stops a local user from creating a fake nsswitch file inside the chroot directory, pointing it toward a malicious shared library, and forcing Sudo to load that code. In plain terms, the attacker prepares a parallel world where their own rules apply, then convinces Sudo to live in it. Once the rogue library is in play, climbing to root is trivial.

What makes the situation worse is that no special sudoers rules are required. A standard installation of a vulnerable Sudo version is enough. As a result, any unprivileged person with shell access — even a temporary account — could seize full control.

Patch Arrives and a Feature Faces Retirement

Both flaws were reported responsibly on April 1 2025 and fixed in Sudo 1.9.17p1, released at the end of May. Miller also said the chroot option will disappear in a future release because supporting a user-defined root path has proven too risky and too hard to secure. The maintainers recommend that administrators who truly need chrooted shells switch to dedicated container or virtualization tools instead of leaning on Sudo.

Distribution Advisories Roll Out

Major Linux and Unix vendors moved quickly once the patches landed. AlmaLinux, Alpine, Amazon Linux, Debian, Gentoo, Oracle Linux, Red Hat, SUSE, and Ubuntu are among the projects that have shipped updated packages. In most cases, a routine system update and a restart of any long-running services that call Sudo are all that is required. Machines left unpatched, especially multi-user servers and development boxes, remain open to privilege-escalation attacks.

What Administrators Should Do Today

Anyone managing Linux or Unix systems should confirm that Sudo 1.9.17p1 or later is installed. Where a shared sudoers file is in use, double-check host-specific rules and consider breaking large, monolithic configurations into smaller, machine-specific files. On systems where the chroot flag is in active use, review the workflow and migrate to safer alternatives before the option disappears. Finally, keep an eye on vendor advisories, because downstream distributions may back-port the fix without bumping the visible version number.

The Broader Lesson

These incidents show how even mature, widely reviewed code can harbor surprises. A feature added for convenience twelve years ago, and a chroot helper meant for edge cases, both turned into steppingstones for attackers. Regular audits, quick patching, and a healthy suspicion of rarely used flags remain the best defense. With the updates now available, the window of exposure can close — but only if administrators act.