Both. Application teams need to assume that a low-privilege shell, poisoned dependency, or compromised build step can become a host-root path when the platform has a matching kernel flaw. Platform teams then own the hardening, patching, and filesystem layout that determine whether that escalation is possible.
Why local privilege escalation belongs to both layers
Local privilege escalation is not just a host problem or just an app problem, because the exploit path usually starts in one place and ends in another. Application code, dependencies, build artefacts, and runtime permissions can create the foothold, while the operating system, kernel, filesystem, and patch state determine whether that foothold can become root. That makes ownership shared, not ambiguous.
Teams get into trouble when they assign the bug to whichever layer first exposed it. If a low-privilege process can reach a vulnerable kernel path, the application team owns the conditions that made the process reachable, but the platform team owns the control surface that turned reachability into full compromise.
In practice, the right question is not “who wrote the bug?” but “which layer controls the blast radius?” That is why local privilege escalation should be discussed in the same conversation as host hardening, runtime isolation, container boundaries, and patch latency.
Where the application boundary ends and the platform boundary begins
Application risk is the right framing when the exploit path depends on app behavior: an exposed admin function, a poisoned dependency, an overly broad service account, a build step that runs with too much privilege, or a workflow that hands untrusted input to a sensitive local interface. In those cases, the app team can change the preconditions even if the final escalation relies on an OS flaw.
Platform risk is the right framing when the decisive failure is in the host environment: missing kernel patches, weak namespace isolation, unsafe filesystem permissions, dangerous device mounts, permissive container settings, or inadequate separation between workloads. A secure application cannot fully compensate for a platform that allows a low-privilege process to cross into root.
The most useful ownership model is therefore split accountability. Application owners should reduce the probability that untrusted code or compromised pipelines reach sensitive local interfaces, while platform owners should reduce the chance that a local exploit becomes host compromise. A shared risk statement keeps both teams focused on the same outcome.
What good looks like in operations and governance
The strongest control posture treats local privilege escalation as a cross-boundary abuse path, then verifies both halves of the chain. Application teams should understand which components execute locally, which dependencies can influence privilege, and which build or deployment steps can introduce hostile code. Platform teams should know which hosts, images, and kernel baselines are still capable of turning that foothold into elevation.
That framing is especially important for modern cloud and build environments. A CI/CD compromise, a container escape, or a poisoned package may begin as an application integrity issue, but the severity depends on whether the underlying host and orchestration layer are hardened enough to resist privilege gain. NHIMG’s Cloud PAM and CIEM Guide is useful here because it ties entitlement right-sizing to escalation-path review, which is exactly the kind of platform-plus-access question local escalation raises.
For teams managing cloud admins and shared platforms, Just-in-Time Access and Zero Standing Privilege Guide helps translate the lesson into operating practice: reduce standing privilege where possible, then make any remaining elevation time-bound and reviewable. That does not remove kernel or host flaws, but it narrows what an escalated process can do after it lands.
Risk and Threat Considerations
Local privilege escalation is attractive because it converts a limited initial compromise into durable control of the host. Once an attacker or malicious process reaches root, they can often disable local defenses, tamper with logs, dump secrets, move into adjacent services, or use the host as a launch point for broader compromise. The real risk is not the bug alone, but the combination of a reachable foothold and a platform that still permits privilege gain.
Failure mechanism: A low-privilege shell, build step, or container process reaches a vulnerable local interface, then exploits a kernel, driver, filesystem, or service misconfiguration to cross the privilege boundary.
Impact: The attacker gains host-level control, which can expose credentials, bypass application controls, and turn a single compromised workload into a pivot into neighboring systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Kernel and host flaws determine whether local escalation succeeds. |
| AC-6 — Least Privilege | Overbroad runtime permissions increase the impact of a local foothold. | |
| CM-6 — Configuration Settings | Filesystem layout and platform hardening often decide whether escalation is possible. | |
| Recommendation — Patch vulnerable hosts and images promptly to reduce privilege-escalation exposure. Restrict runtime permissions so local compromise cannot easily become root. Harden host and container settings that control privilege escalation paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Least privilege directly reduces the blast radius of a local escalation bug. |
| Recommendation — Apply least-privilege access to limit what an exploited process can do. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Secure host and software configuration is central to blocking local escalation. |
| Recommendation — Enforce hardened baselines on hosts, images, and deployed software. | ||
Practitioner Guidance
What to prioritise: Classify every escalation path by the layer that can actually stop it. If patching or hardening the host breaks the path, platform owns the control; if unsafe execution or overbroad runtime permissions create the foothold, application owns the reduction in exposure.
What to verify: Confirm whether the vulnerable condition exists on the current kernel, image, or host baseline, and whether the application or pipeline can reach it without an unnecessary privilege grant. If either answer is “yes,” treat the issue as active risk rather than theoretical exposure.
Practitioner takeaway: The right operating model is shared ownership with clear control boundaries, because local privilege escalation becomes serious only when an application weakness meets a platform that can still be turned into root.
Related resources from NHI Mgmt Group
- How do security teams reduce risk from local kernel privilege boundary bugs?
- How can security teams measure whether local privilege escalation risk is actually controlled?
- How should security teams reduce the risk of local privilege escalation on Linux hosts that run untrusted code?
- How should security teams reduce privilege escalation risk when a Windows flaw exposes local admin paths?