TL;DR: Privilege escalation is gaining authority you were not meant to have. Vertical escalation moves up a level (a web user becomes an administrator, a service account becomes root). Horizontal escalation moves sideways to a peer's authority at the same level (user A reads user B's invoices by changing an ID). Privilege moves in four ways: a bug in something more privileged that trusts your input, a misconfiguration that grants more than intended, stolen credentials for a more privileged identity, and a design flaw where a check is missing. Defences follow the same list: least privilege, fewer privileged components, protected credentials and server-side authorization on every request.
How to approach it
Give the definition with one example per direction, from two layers (operating system and application), so the interviewer sees you treat it as a general concept. Then explain how privilege actually moves, because that is what decides the controls. Finish with how you would find escalation paths in a system you are responsible for.
A strong answer
Bug in something privileged
It trusts your input
- Kernel flaws, setuid binaries, privileged services
Defence: patching, memory safety, sandboxing the parser.
Misconfiguration
Granted more than intended
- Writable scripts run by root, broad sudo, open sockets
Defence: least privilege, configuration review.
Stolen credentials
Become a stronger identity
- Keys in files, tokens in memory, reused passwords
Defence: short-lived credentials, secret managers, MFA.
Missing check
Design flaw
- Horizontal: change an ID, read a peer's data
- Vertical: an admin endpoint without role checks
Defence: authorisation on every request.
Two directions.
| Operating system | Web or API | |
|---|---|---|
| Vertical | A compromised web server account gains root | A normal user reaches an admin endpoint that only hides its button in the UI |
| Horizontal | One user reads another user's home directory | User A fetches /invoices/1042, which belongs to user B |
Horizontal escalation is the more common finding in web applications: OWASP lists broken access control first in its web Top 10, and insecure direct object references are the everyday form. Vertical escalation is the more common goal in host compromise, because root or SYSTEM turns one foothold into control of the machine.
How privilege moves.
- A privileged component trusts your input. A setuid program, a Windows service, a kernel driver or an admin API processes data you control. A memory bug, command injection or path trick in it runs your choice with its privileges. Every privileged component that reads untrusted input is an escalation surface; fewer and smaller ones mean fewer paths.
- Misconfiguration grants too much. A
sudorule that allows an editor or interpreter, a world-writable script run by root's scheduler, a service binary path users can replace, a container started with the host's Docker socket mounted, a cloud role that can attach a more powerful policy to itself. These are the majority of real escalations because they need no exploit, only enumeration. - Stolen credentials. Passwords in scripts and shell history, tokens in environment variables, SSH keys readable by the wrong user, cached admin credentials on a workstation. The attacker does not break anything; they become someone more privileged.
- A missing check. The authorization decision was never made: an endpoint that checks you are logged in but not that the object is yours, an internal API that trusts whoever reaches it.
Finding the paths in your own system. Inventory every place privilege changes hands: setuid binaries, services and their file permissions, sudo rules, scheduled tasks, IAM policies that can modify IAM, admin APIs. For each, ask who can influence it. For applications, test every object-level endpoint with a second user's identifiers; that single test finds most horizontal escalations. In cloud, graph who can grant themselves what (iam:PassRole, policy attachment, role assumption chains); identity-graph tools exist because these paths are hard to see by reading policies one at a time.
Defences, mapped to the four ways. Least privilege (services run as dedicated accounts with only the capabilities they need), fewer privileged components (replace setuid with narrow capabilities or a broker), credential hygiene (short-lived credentials, no secrets in files the service user can read), and authorization enforced on the server on every request. Detection covers the rest: alert on new setuid files, on processes changing user unexpectedly, on IAM policy changes.
The AI version of the same idea: an agent that holds a service account broader than the user it serves is a vertical escalation waiting for a prompt injection, and an agent that fetches documents by ID without a per-user check is a horizontal one.
What interviewers probe next
- "Is IDOR vertical or horizontal?" Usually horizontal (a peer's object), vertical when the object is an admin resource. Either way the fix is an ownership check on the server.
- "Which is more dangerous?" Depends on what the target identity can reach. A horizontal escalation to a tenant administrator's data can be worse than a vertical one on an empty machine.
- "How would you detect escalation on a Linux fleet?" Process lineage where a low-privilege parent spawns a root child unexpectedly, sudo and su logs, new setuid files, changes to sudoers and cron.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
An attacker has a shell as the www-data user on a Linux web server.
Start here
What is privilege escalation?
Up or sideways?
Gaining authority you were not meant to have. Vertical escalation moves up a level, such as www-data to root. Horizontal moves sideways to a peer's authority, such as one user reading another's invoices.
Carry it forwardVertical and horizontal escalation.
Weak answerThinking escalation only means root.
Constraint changes
Where does privilege usually come from?
Which routes need no exploit at all?
Misconfiguration (sudo rules, writable files run by privileged processes, setuid programs), exposed secrets (credentials in files or environment), vulnerable privileged software, and kernel bugs.
Carry it forwardMisconfiguration and secrets are the common routes.
Weak answerAssuming escalation needs a kernel exploit.
Constraint changes
What would a defender check on this server?
What can www-data read, write and run?
Sudo rules for www-data, setuid binaries, files writable by www-data that root runs, readable secrets such as database passwords, privileged sockets, and the kernel's patch level.
Carry it forwardAudit what the account can reach.
Weak answerChecking only the kernel version.
Constraint changes
Why does horizontal escalation matter?
What could www-data read through the database?
Reading another customer's data through the application is often more damaging than root on one server. Application authorisation is part of privilege management.
Carry it forwardHorizontal escalation can be the bigger breach.
Weak answerIgnoring application data access.
Constraint changes
How do you limit what www-data leads to?
What would make the shell a dead end?
No sudo, no writable privileged paths, secrets fetched with narrow scope, least-privilege database accounts, sandboxing with systemd or containers, patched kernels and monitoring for unusual processes.
Carry it forwardMake the service account a dead end.
Weak answerRelying on attackers not finding paths.
Now defend it
How would you make this server resistant?
Remove sudo and writable privileged paths for www-data, minimise setuid binaries, keep secrets narrowly scoped and unreadable by default, use least-privilege database accounts with per-object authorisation, sandbox the service, patch the kernel and monitor for unusual process launches.
How it's scored
Weak: Defines vertical escalation only, with "use a kernel exploit" as the example.
Hire: Gives both directions with OS and web examples, explains misconfiguration and credentials as common paths, and names least privilege and server-side authorization.
Strong Hire: Organises the answer by the four ways privilege moves, explains how to enumerate paths in an estate including cloud IAM, maps controls to each way, and connects it to agents holding broader credentials than their users.
Common mistakes
- Treating escalation as synonymous with kernel exploits.
- Hiding admin functions in the UI and calling that authorization.
- Forgetting horizontal escalation entirely.
- Ignoring credentials lying around as an escalation path.