TL;DR: Two sudo vulnerabilities, CVE-2025-32462 and CVE-2025-32463, let local users bypass host checks or load malicious libraries with root privileges, affecting Linux and macOS systems and prompting CISA KEV inclusion for the latter, according to Oligo Security. The bigger lesson is that privilege boundaries built for stable administrative workflows fail fast when elevation paths are exploitable at runtime.
At a glance
What this is: This analysis covers two sudo privilege escalation flaws that can grant root access on Linux and macOS systems by bypassing host checks or loading attacker-controlled libraries.
Why it matters: IAM, PAM, and NHI teams should treat local elevation paths as governance boundaries, because exploitable privilege logic can turn ordinary administrative workflows into root-level compromise routes.
Context
Sudo is the standard privilege elevation tool on many Linux and macOS systems, so flaws in its policy checks affect the boundary between ordinary user access and root access. When that boundary can be bypassed, the issue is not just a software bug. It becomes a governance failure for privileged execution.
This article is about two sudo vulnerabilities, one that bypasses host-specific policy and one that forces malicious library loading during chroot handling. Both expose a control assumption that elevation decisions will be evaluated before privileged execution begins. For NHI and PAM teams, that is a reminder that runtime privilege paths need continuous scrutiny, not just approved configuration.
Key questions
Q: What breaks when sudo privilege checks can be bypassed locally?
A: A local user can move from limited command execution to root-level control without crossing the normal policy boundary. That breaks the assumption that privilege escalation is only possible through approved admin workflows. In practice, host-scoped sudoers rules, chroot handling, and package-version checks all become weaker than they appear unless the live binary and execution path are verified.
Q: Why do sudo privilege escalation flaws create broader risk than a single host compromise?
A: Because root access is a control boundary, not just a machine-level privilege. Once an attacker can execute as root on one host, they can disable security tooling, alter trust settings, and pivot through the environment using the compromised system as an administrative foothold.
Q: What signs indicate sudo is still exposing privilege escalation risk?
A: Look for running sudo binaries that do not match the patched release, sudoers files that depend on host-specific rules, and writable directories being involved in privileged workflows. If package inventory says the system is fixed but the live binary is not, the exposure is still real.
Q: Should teams prioritize sudo policy cleanup or emergency patching first?
A: Patch first, because the exploitable logic sits in the privilege evaluator itself. Policy cleanup matters next, but it does not remove the immediate risk if vulnerable binaries remain in production. The right sequence is exposure removal before configuration refinement.
Technical breakdown
Host-check bypass in sudo policy evaluation
CVE-2025-32462 affects sudo's handling of the -h or --host option. The option was meant for listing privileges with sudo -l, but affected versions accepted it on other commands, which made sudo think the command was being run on an allowed host. That let a local user with limited sudo access bypass host-specific rules and execute as root. The failure sits in policy evaluation, not in authentication, because the user was already authorised to invoke sudo, but the host constraint was misapplied.
Practical implication: Treat host-scoped sudo rules as a brittle control and verify that policy evaluation blocks -h outside listing mode.
Chroot abuse and malicious library loading
CVE-2025-32463 is a privilege escalation bug in sudo's -R or --chroot handling. A writable directory such as one under /tmp can be prepared with fake system files like /etc/nsswitch.conf and a malicious libnss_*.so library, then fed into sudo before privilege checks complete. Because sudo could switch context too early, it loaded attacker-controlled code with root privileges. The issue is a classic trust-boundary mistake: the runtime environment became part of the privilege decision.
Practical implication: Remove deprecated chroot behaviour from sudo policy paths and block writable directories from influencing privileged library resolution.
Why runtime privilege checks are the real control surface
These flaws show that privileged execution is governed by more than usernames and sudoers syntax. The decisive control surface is the sequence in which sudo validates context, resolves options, and loads execution dependencies. If that sequence can be altered, an attacker can move from a valid local session to root without changing identity. For identity programmes, that makes elevation logic a lifecycle problem: who can execute, under what context, and with which environmental assumptions.
Practical implication: Map every privileged workflow to the exact point where context is validated, then test whether that order can be subverted.
Threat narrative
Attacker objective: Gain root-level control on affected hosts so security measures can be disabled and the environment can be used for further intrusion.
- Entry occurs through an existing local user session on a Linux or macOS host where sudo is available.
- The attacker abuses sudo policy handling, either by bypassing host checks with -h or by steering sudo into attacker-controlled chroot content.
- Privilege escalation follows when sudo executes commands or loads libraries as root, giving the attacker administrative control.
- Impact includes disabling protections, manipulating the host, and moving deeper into the network from a trusted privileged foothold.
Breaches seen in the wild
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Privilege boundaries built for stable administrative workflows are now a governance liability. Sudo assumes that context checks, option handling, and execution remain aligned long enough for policy to be enforced. These flaws show that a local user can cross the boundary from permitted elevation to root execution when that sequence is mis-evaluated. The practitioner conclusion is simple: privileged access governance must treat runtime behaviour as the control surface, not just the configured rule set.
Host-scoped sudo policy is a fragile identity assumption. Host-specific rules presuppose that the host context is trustworthy and evaluated before execution begins. CVE-2025-32462 breaks that premise by letting -h influence commands that were never meant to use it. The named concept here is runtime privilege boundary drift, where an elevation rule ceases to describe the actual execution path. Practitioners should recognise that policy expressed in sudoers is not enough if the evaluator can be steered off path.
Environment-controlled library resolution is an overprivilege amplifier, not just a code-loading issue. CVE-2025-32463 shows that writable directories can become part of the privilege decision when chroot handling happens too early. That is an NHI-style governance lesson because the execution context, not a human operator, determines whether code runs as root. The implication is that privileged workflows must be judged by where trust is inherited from the environment, not only by who started the session.
Standing administrative workflows need a shorter trust window than most Linux programmes assume. These flaws expose the gap between an approved elevation request and the moment privileges are actually consumed. If the control only validates at the start, but execution dependencies can still be influenced mid-path, the governance model is too coarse. Practitioners should revisit every root path where validation and execution are separated by mutable runtime state.
Privilege escalation bugs like these are a reminder that PAM and NHI governance overlap at the execution layer. The same policy question appears across human admin access and service-driven automation: who can cause privileged action, under what state, and with what inherited context. When that answer depends on runtime internals rather than explicit governance, the control model is already behind. The practitioner conclusion is to align privilege controls with execution order, not just access intent.
From our research library:
- Only 26% of known exploited vulnerabilities were fully remediated in 2025, down from 38% the year before, according to Verizon's 2026 Data Breach Investigations Report.
What this signals
Runtime privilege boundary drift: sudo demonstrates how an elevation rule can be correct on paper and still fail when the evaluator accepts the wrong context at runtime. That matters because many identity programmes still treat privileged access as a configuration problem, when the real failure is often in execution order and environment trust.
For teams running PAM, Linux hardening, or NHI governance, the practical shift is to inspect where policy and execution are separated by mutable state. If a privileged path can be influenced by writable files, option parsing, or stale binaries, the control boundary has already moved.
For practitioners
- Patch sudo to the fixed release everywhere Install sudo 1.9.17p1 or your distribution's back-ported package on every host, then verify the running binary with sudo -V so package metadata does not mask an exposed version.
- Audit host-specific sudoers rules Search /etc/sudoers* for rules that rely on host fields other than ALL, then replace them where possible with group-based or tag-based controls that do not depend on host-check parsing.
- Remove deprecated chroot-based elevation paths Disable use_chroot and delete any CHROOT= or runchroot=* directives so sudo does not evaluate privilege decisions in a writable directory context.
- Harden world-writable execution surfaces Remount /tmp, /var/tmp, and /dev/shm with nosuid,nodev,noexec where operationally safe so attacker-controlled libraries cannot be staged for privileged loading.
- Verify live runtime exposure, not just package state Continuously confirm which sudo binaries are actually executing in memory and alert when version claims and live process state diverge across production hosts.
Key takeaways
- The article shows that local privilege escalation can begin with ordinary sudo usage and end in root access when policy evaluation is bypassed.
- Oligo Security links the issue to two sudo flaws, including CVE-2025-32463, which was added to CISA's Known Exploited Vulnerabilities catalog.
- The limiting control is not just patching, but verifying the live binary, removing risky sudo policy patterns, and eliminating writable execution paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Sudo flaws turn routine elevation paths into overprivileged execution channels. |
| NHI-06 — Insecure Cloud Deployment Configurations | Writable directories and unsafe privilege settings create misconfigured execution conditions. | |
| Recommendation — Reduce sudo and other privileged paths to the minimum execution scope needed and remove unnecessary root pathways. Harden execution environments so privileged workflows cannot inherit trust from writable paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article is fundamentally about privilege boundaries failing open at runtime. |
| Recommendation — Apply least privilege to sudo paths and remove host-specific exceptions that broaden root access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Privilege escalation risk is amplified when admin access and rule-based exceptions are poorly governed. |
| Recommendation — Review privileged account assignments and eliminate sudo rules that exceed operational need. | ||
| MITRE ATT&CK | TA0004;TA0006 — Privilege Escalation; Credential Access | The exploit path is an elevation-of-privilege technique that can support later credential abuse. |
| Recommendation — Map sudo exposures to privilege escalation patterns and hunt for post-escalation activity on affected hosts. | ||
Key terms
- Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
- Policy Evaluation: Policy evaluation is the process of interpreting rules against request context to produce an allow or deny decision. For workload identity, the critical question is not only whether the decision is correct, but whether the evaluation engine is safe, observable, and maintainable in the chosen runtime.
- Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.
- Host-Scoped Rule: A host-scoped rule is a privilege control that applies only on selected systems or host identities rather than universally. These rules can create fragile assumptions if the host context is parsed incorrectly or evaluated too late, which makes the control easier to bypass in practice.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org