Home Articles Categories SecurityClaw Demos Tools Privacy

Key Takeaways

Why Privilege Escalation Pays Well

Privilege escalation sits at the intersection of access control and business logic — two areas where automated scanners consistently fail. A scanner can find a reflected XSS in seconds, but it cannot understand that changing role=user to role=admin in a POST body grants full administrative access. That's why privesc bugs command high payouts: they require human reasoning, and they almost always have direct business impact.

In 2026, broken access control remains the #1 category in the OWASP Top 10. Programs on HackerOne and Bugcrowd routinely pay $1,000–$15,000+ for privilege escalation findings, depending on impact.

Vertical vs. Horizontal Privilege Escalation

Vertical privilege escalation means moving up the permission hierarchy — user to moderator, moderator to admin, admin to superadmin. These are typically critical severity because they give an attacker capabilities they were never intended to have.

Horizontal privilege escalation means accessing resources belonging to another user at the same privilege level — viewing another user's profile, modifying their settings, or reading their private data. These are typically high severity and often overlap with IDOR.

The most impactful findings chain both: start with horizontal access to discover an admin user's ID, then use that ID to escalate vertically.

The Two-Account Method

Every privilege escalation test starts with two accounts:

  1. Account A — the highest-privilege role you can access (admin, manager, team lead)
  2. Account B — the lowest-privilege role (free user, viewer, guest)

The workflow:

  1. Log in as Account A and map every endpoint, action, and API call available to that role
  2. Log in as Account B in a separate browser or Burp session
  3. Replay Account A's requests using Account B's session token
  4. Any request that succeeds is a privilege escalation bug

This sounds simple, and it is — but most hunters skip it because it's tedious. Autorize automates step 3.

Setting Up Autorize for Automated Testing

Autorize is a Burp Suite extension that replays every request with a lower-privileged session cookie automatically. Setup:

  1. Install Autorize from the BApp Store
  2. Log in as Account B (low-priv) and copy the session cookie
  3. Paste the cookie into Autorize's configuration
  4. Browse the application as Account A (high-priv)
  5. Autorize replays every request with Account B's cookie and flags responses that match — meaning the low-priv user got the same data

Color coding: red = enforced (access denied), orange = possible bypass (similar response), green = confirmed bypass (identical response). Focus on the green and orange results.

Common Privilege Escalation Vectors

1. Role Parameter Manipulation

Some applications include the user's role in the request body during registration or profile updates:

POST /api/users/register
{"email": "user@example.com", "password": "...", "role": "user"}

Change "role": "user" to "role": "admin". If the server doesn't validate this server-side, you've just created an admin account. This is more common than you'd expect — especially in applications built with frameworks that auto-bind request parameters to database models (mass assignment).

2. JWT Claim Tampering

JWTs often contain role or permission claims in the payload:

{"sub": "12345", "role": "user", "iat": 1713000000}

Attack vectors:

Use jwt_tool to automate these checks: python3 jwt_tool.py <token> -M at runs all known attack modes.

3. IDOR-to-Admin Chains

Sometimes you can't directly escalate your role, but you can access admin resources through predictable IDs:

  1. Find an endpoint like GET /api/users/123/settings
  2. Enumerate user IDs (often sequential) to find admin accounts
  3. Access admin-specific endpoints using the discovered admin user ID
  4. Modify admin settings, reset admin passwords, or extract admin API keys

4. Forced Browsing to Admin Panels

The UI hides admin links from regular users, but the endpoints still exist:

Use wordlists like SecLists' raft-medium-directories.txt with ffuf or feroxbuster. Then test each discovered endpoint with your low-priv session token.

5. HTTP Method Switching

Some applications enforce authorization on GET but not on PUT, POST, or DELETE for the same endpoint:

GET /api/users/456 → 403 Forbidden
PUT /api/users/456 → 200 OK (modifies the user)

Always test multiple HTTP methods on every endpoint you find.

6. Path Traversal in Authorization

Middleware that checks paths may be bypassable with path manipulation:

Testing GraphQL for Privilege Escalation

GraphQL APIs are particularly prone to privesc because:

Start with introspection: {"query": "{__schema{types{name,fields{name}}}}"}. Look for mutations like updateUserRole, deleteUser, adminSettings, or any field containing "admin", "role", "permission".

Multi-Step Escalation Chains

The highest-paying privesc bugs aren't single-step — they're chains. A realistic example:

  1. Information disclosure — enumerate user IDs via a public API endpoint
  2. Horizontal privesc — access another user's profile via IDOR
  3. Discover admin user — find a user with "role": "admin" in the response
  4. Password reset takeover — trigger a password reset for the admin account via an unprotected endpoint
  5. Vertical privesc — log in as admin with the new password

Document every step with screenshots and HTTP request/response pairs. Chains that demonstrate full account takeover consistently receive critical severity ratings.

Proving Impact in Your Report

A privesc report that says "I can access admin endpoints" gets triaged as medium. A report that demonstrates concrete impact gets critical. Show:

Checklist: Privilege Escalation Testing

  1. ☐ Create accounts at every available role level
  2. ☐ Map all endpoints accessible to the highest-privilege role
  3. ☐ Set up Autorize with the lowest-privilege session cookie
  4. ☐ Browse as high-priv and review Autorize results
  5. ☐ Test role parameters in registration and profile update endpoints
  6. ☐ Check JWT claims for role/permission fields and test tampering
  7. ☐ Enumerate user IDs and test IDOR on admin-specific endpoints
  8. ☐ Fuzz for hidden admin paths with ffuf/feroxbuster
  9. ☐ Test HTTP method switching on all restricted endpoints
  10. ☐ Try path traversal bypasses on authorization middleware
  11. ☐ If GraphQL: run introspection and test admin mutations
  12. ☐ Document chains with full request/response evidence

Frequently Asked Questions

Do I need multiple accounts to test for privilege escalation?

Yes. Two accounts minimum — one high-privilege and one low-privilege. Some programs provide test accounts; others let you create multiple accounts. If the program only allows one account, you can still test by modifying your own role parameters and JWT claims, but two-account testing is far more thorough.

Is horizontal privilege escalation worth reporting?

Absolutely. Accessing another user's data is a privacy violation and typically rated high severity. If you can chain it into vertical escalation or account takeover, it becomes critical.

What's the difference between IDOR and privilege escalation?

IDOR (Insecure Direct Object Reference) is a specific vulnerability type where changing an object identifier gives you access to another user's resource. Privilege escalation is the broader impact — IDOR is often the mechanism that enables it. An IDOR that lets you access admin resources is a privilege escalation.

Advertisement