Vertical Privilege Escalation

What Is Vertical Privilege Escalation?

Vertical privilege escalation is the higher-impact sibling of IDOR. Where horizontal escalation lets one regular user reach another regular user's data, vertical lets a low-privilege user climb the ladder to administrator, because the authorization gate trusts a value the attacker controls. This exercise puts you on both sides. As Bob, a contractor holding a read-only viewer seat on Talveyn's internal operations console, you find that your role travels inside the JWT session cookie your own browser is holding. You open the cookie inspector, rewrite the role claim from viewer to admin, reload the admin area, and walk straight in, no password stolen, no session hijacked. As Alice, the application security engineer, you arrive from a monitoring alert (a viewer seat calling admin-only endpoints), open the shared admin gate, and find it decoding the token without ever verifying it. You ship the fix, verify the signature with the server's secret before trusting a single claim, then watch the same forged token get refused. The exercise closes with quiz questions on what separates vertical from horizontal escalation, why decoding a token is not the same as trusting it, and what the attacker sees once verification ships.

What You'll Learn in Vertical Privilege Escalation

• Distinguish vertical from horizontal privilege escalation by where the attacker moves in the role hierarchy
• Recognize that authentication (proving who you are) is separate from authorization (proving you may do this)
• Understand that any role, tier, or permission carried in a client-held token or cookie is attacker-controllable until its integrity is verified
• Apply the fix that verifies a token's signature before trusting a claim, so a forged role is rejected
• Add a server-side backstop by re-deriving privileges from trusted records and enforcing least privilege

Vertical Privilege Escalation — Training Steps

1. A read-only seat

   Bob holds a legitimate but low-privilege account on Talveyn's Operations Console, a contractor's read-only viewer seat. He signs in with his own credentials, exactly as he is entitled to. No password stolen, no account cracked. He lands on his viewer home. He can see his support queues, and one card he is not meant to touch: the Admin Console.

2. The locked door

   Bob opens the Admin Console from his dashboard anyway, just to see how far his seat gets. The server turns him away with a restriction notice. The gate is real. The interesting question is what that gate actually checks.

3. The role rides in the token

   Bob opens the browser's cookie inspector. His session is a JWT, and the console decoded it into readable claims: who he is signed in as, and the role it grants him. There it is, in plain view: a role claim reading viewer. The very value the gate checks is sitting in a token his own browser is holding.

4. Forge the role

   If the console reads his role straight from the token, and the token is in his browser, then he can rewrite it. Bob edits the role claim from viewer to admin. The inspector re-encodes the token with the new claim. The signature no longer matches the payload, but that only matters if the server bothers to check.

5. Inside the Admin Console

   Bob reloads the Admin area, this time carrying the forged token. The gate reads admin from his claims and swings the door open. He now holds the full administrator surface: every user's record, the power to change any role, export the entire directory, and reach billing and payouts. A read-only seat, twenty seconds ago.

6. Name what happened

   Before Bob's mess becomes Alice's morning, be precise about the escalation.

7. A viewer with admin hands

   Alice owns the console's access controls. Overnight, monitoring flagged something that should be impossible: a viewer-seat session performing administrator-only actions. Security Operations has emailed her the finding.

8. Open the admin gate

   Every admin route shares one gate, require-admin.js . Alice opens it to see exactly how it decides who counts as an administrator.

9. The gate trusts the token

   The gate pulls the caller's role out of the session token and compares it to admin. What it never does is check that the token is genuine. A payload rewritten in the browser decodes just fine, so a forged role passes straight through.

10. Pick the real fix

    You have seen the bug. Choose the change that actually closes it.