Sudo Vulnerability Discovered, May Exposes Linux Systems

Philipp Katzenberger via Unsplash
Sudo, the privileged command-line tool often installed on Linux systems, has two local privilege vulnerabilities.
These vulnerabilities were discovered by the research team at Stratascale and can result in root privilege escalation.
Below, security leaders discuss the risks of these vulnerabilities as well as management strategies.
Security Leaders Weigh In
Marc England, Security Consultant at Black Duck:
CVE-2025-32462 has received a lower CVSS score due to the conditions that are needed. Namely, successful execution would require someone to make a misconfiguration and deploy a Sudoers file with an incorrect host for this vulnerability to work. The error has to happen elsewhere to meet these conditions.
CVE-2025-32463 on the other hand, involves a local privilege escalation vector that doesn’t require the user to be in the Sudoers file. My only question to it would be, when it comes to elements such as infrastructure, how many of them are using Ubuntu 24.04? A lot of the time with Ubuntu 22.04 LTS having support through to 2027, it would be far more common in most environments as there isn’t always a rush to update to a new OS since the current one is still stable and supported. I’m not sure how many would have upgraded as Sudo 1.9.9 — the latest package for Ubuntu 22.04 (and not in the vulnerable range).
Ben Hutchison, Associate Principal Consultant at Black Duck:
Both the recently disclosed Sudo vulnerabilities should be treated as priorities for resolution by organizations, as both enable potential elevation of user privileges and unintended execution of commands on impacted devices/across an organizations environment. In the case of the lower rated severity issue, the conditions for the vulnerability to be exploited require that specific configuration conditions are met in the affected environment, outside the default; however those conditions are not that unlikely as the functionality being exploited is an unintended operation available by default if the requisite environmental/configuration conditions are met, which exist to meet a relatively common need; namely use of a common configuration file intended to specify discrete user permission conditions used across hosts, leveraging the use of supported host/host alias configuration file options intended to simplify the management of complex environmental deployments.
Unfortunately, in this case, using this intended functionality opens organizations up to unintended consequences through the use of this feature in other unintended command contexts which enables the potential elevation of user privileges and command execution across hosts beyond that intended and which flies in the face of the expected configuration, which can have serious consequences; organizations should treat remediation of the issue as a priority despite the seemingly low vulnerability severity score and investigate their configurations for use of the vulnerable options and versions (doubly so due to the presence of the other recently disclosed vulnerability which does not have such configuration based requirements for exploitation).
Trey Ford, Chief Information Security Officer at Bugcrowd:
Permissions control, specifically maintaining positive control of privilege escalation, is critical to security operations. When Sudo needs patched, you put down your sandwich and get that prioritized ASAP.
These super tricky vulnerable edge cases are the beauty of research partnership. The variance in scoring makes sense — there’s a very narrow configuration scenario allowing for one exploit, where a userland file can be created to exploit the other.
Vulnerabilities in open source software can often linger — when we add functionality to foundational open source projects, they live until found (in this case, a dozen years) — leaving defenders asking "how do we investigate to see if this has been used maliciously in the past? (Note: these can be very expensive investigations due to the volume and storage patterns for old logs).
Research teams looking to make a name for themselves should take the time to study major open source packages like this — evaluating when new functionality has been added to look for these edge cases. The power of research isn’t in the actual review — it’s in the diversity of the reviewers testing the code from every imaginable angle.
Looking for a reprint of this article?
From high-res PDFs to custom plaques, order your copy today!