Vertical Privilege Escalation

What Is Vertical Privilege Escalation?

Horizontal escalation moves sideways into another user's data. Vertical escalation climbs the ladder, because the authorization gate trusts a value the attacker is holding. You'll find your role travelling inside a JWT session cookie, rewrite the claim from viewer to admin, and walk into an operations console with no stolen password and no exploit code. The gate decodes the token and reads the claim without checking the signature, and decoding proves nothing. The fix verifies the signature first, with privileges re-derived server-side from trusted records as the backstop.

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.