Hey everyone! I’m Husnain, a Jr. Penetration Tester, and during one of my recent engagements I came across a Vertical Privilege Escalation bug that honestly surprised me with how simple it was. No fancy exploit chain, no CVE – just a missing server-side check and one intercepted request.
The Bug
The application had a multi-tier role system: Superadmin at the top, Client Admin below, and a user. The Superadmin had the ability to create custom roles – and here’s the catch:
If that custom role was cloned from the Superadmin with equal privileges, a Client Admin with user-creation rights could assign it to a newly created user.
Why? Because the server only checked whether the Client Admin could create users – it never validated what role they were allowed to assign.
The role ID was passed in the request body, totally unguarded. Change it to the custom Superadmin role ID, forward the request, and the new account lands with full Superadmin privileges.
Two intercepted requests. One parameter change.
The Impact
This is a High severity finding. A Client Admin exploiting this could access restricted platform functions – things like global email templates and configurations, that are completely outside their scope.
The scariest part? It leaves almost no footprint. To the logs, it just looks like a routine user creation event. In a multi-tenant environment, the blast radius gets even worse.
The Fix
The root cause is classic: UI-level restrictions were the only enforcement in place.
The server trusted whatever role ID the client sent.
The fix is two things:
- A server-side role boundary check that rejects any assignment where the assigned role is equal to or higher than the requester’s own privilege level.
- And an allowlist of assignable roles scoped strictly to tiers below the requesting admin.
UI dropdowns are a UX feature. Server-side validation is a security feature. Never confuse the two.
That’s it for today! If you found this helpful, consider to drop a comment!