Privilege escalation is the act of exploiting a vulnerability, design flaw or misconfiguration to obtain rights that were never granted to a user, process or service, such as moving from an ordinary account to root, SYSTEM or a cloud administrator role. In cybersecurity it is treated both as a class of vulnerabilities and as a distinct stage of an attack, typically the step that turns a limited foothold into full control.
Among vulnerabilities, privilege escalation flaws are usually less dramatic than remote code execution, because the attacker must already have some access. In practice, however, most serious intrusions chain an entry point with an escalation, which makes these flaws central to patch prioritization and hardening.
Vertical and horizontal privilege escalation
Privilege escalation takes two basic forms. Vertical escalation raises the level of rights, for example from a web server account to root. Horizontal escalation keeps the same level but crosses into another identity, such as one customer reading another customer’s invoices. Both break the authorization boundary that the system is supposed to enforce.
| Form | Movement | Typical example |
|---|---|---|
| Vertical | Lower to higher privilege | Local user gains root through a kernel bug |
| Horizontal | Peer to peer at the same level | User A changes an ID to view user B’s data |
| Local | Requires existing code execution | Abuse of a setuid binary on a server |
| Remote chain | Entry flaw plus escalation flaw | RCE as service account, then kernel exploit |
| Cloud or identity | Misused permissions in an IAM system | Role that can attach admin policies to itself |
Horizontal flaws in web applications are often classified as broken access control or insecure direct object references, while vertical flaws in operating systems usually appear as local privilege escalation (LPE) vulnerabilities in advisories.
Common mechanisms behind escalation
Escalation always exploits a place where a more privileged component trusts input from a less privileged one. That trust boundary can sit in the kernel, a setuid program, a service configuration or an identity policy. The table groups the most frequent root causes.
| Mechanism | Platform | Illustration |
|---|---|---|
| Kernel memory bugs | Linux, Windows | Race conditions and use-after-free in drivers |
| Setuid and sudo misuse | Linux, Unix | sudo rule allowing a shell-capable editor |
| Weak service configuration | Windows | Unquoted service paths, writable service binaries |
| Token and credential abuse | Windows, Active Directory | Impersonation privileges, reused admin passwords |
| Path and library hijacking | All | Writable directory searched before system paths |
| Over-broad IAM permissions | Cloud | Permission to pass any role to a new resource |
| Missing server-side checks | Web applications | Role field accepted from the client |
Several well-known Linux flaws illustrate the pattern. Dirty COW (CVE-2016-5195) abused a copy-on-write race to write read-only files, Dirty Pipe (CVE-2022-0847) overwrote cached file pages, and PwnKit (CVE-2021-4034) exploited argument handling in the setuid program pkexec. Each allowed an unprivileged local user to become root.
How privilege escalation is classified and scored
Privilege escalation is described by several neighboring frameworks, and each answers a different question. A CVE identifier names a specific flaw, a CWE category names the weakness type, and CVSS expresses severity through its metrics.
| Framework | How it represents escalation | Practical meaning |
|---|---|---|
| CVE | Individual advisory for a flaw | Tracks patches for one bug |
| CWE | Weaknesses such as CWE-269 improper privilege management | Explains the coding or design error |
| CVSS | Privileges Required, Attack Vector and Scope metrics | Local LPE often scores high but not critical |
| MITRE ATT&CK | Privilege Escalation tactic with many techniques | Maps attacker behavior for detection |
Because a typical LPE has a local attack vector and requires low privileges, its CVSS base score often lands in the high range rather than the critical one. That number can mislead: on a shared server or a host already exposed by another flaw, an LPE may be the most urgent patch in the fleet.
Preventing and detecting escalation
Defense rests on the principle of least privilege combined with fast patching. Every account, service and role should hold only the rights it needs, so that a compromised component has little to escalate from and few trusted paths to abuse.
- Patch kernels and setuid components quickly, since public LPE exploits often appear within days of disclosure.
- Audit sudo rules and setuid binaries regularly and remove entries that allow shells, editors or arbitrary file writes.
- Run services under dedicated, unprivileged accounts and confine them with mechanisms such as SELinux, AppArmor or systemd sandboxing.
- Use unique local administrator passwords on Windows hosts to stop one stolen credential from unlocking every machine.
- Review cloud IAM policies for permissions that allow modifying roles, passing roles or creating access keys.
- Monitor for escalation behavior such as new administrators, unexpected root shells and changes to service binaries.
Detection matters because prevention is never complete. EDR agents and audit logs can flag a web server process that suddenly spawns a root shell, which is a far more reliable signal than waiting for a signature of a specific exploit.
Misconceptions about privilege escalation
One common belief is that local flaws are low risk because attackers need prior access. In reality, initial access is cheap: phishing, stolen credentials and vulnerable web applications supply it daily. Another misconception is that containers prevent escalation; a container that runs as root, mounts the Docker socket or uses privileged mode can give an attacker control of the host.
Finally, escalation is not only a technical exploit. Misconfigured permissions cause many real incidents without any software bug, which is why configuration reviews belong in every vulnerability management program alongside patching.
In everyday language
Picture an office building where a visitor badge opens only the lobby. Privilege escalation is any trick that lets the visitor turn that badge into a master key, perhaps through a broken lock, a careless guard or a door propped open.
In computers, the badge is a user account and the master key is administrator control. Attackers rarely get the master key first. They start small and climb, which is why fixing these weaknesses matters even when they seem to require someone already inside.
Seen in the real world
A security team investigates an alert on a Linux web server. An attacker exploited an outdated plugin to run commands as the www-data account, which could read web files but not system configuration. Within an hour, the logs show a root shell launched from the same process tree.
The investigation finds that the server still carried a vulnerable pkexec version, and a public exploit gave the attacker root in seconds. The team rebuilds the server, applies all pending security updates across the fleet and adds a detection rule for root shells spawned by web server processes. A follow-up audit removes seventeen unnecessary sudo rules found on other hosts.