Home / Knowledge hub / Role escalation
Knowledge hub
Role escalation
Changing your own role, or another's, through a flaw in how roles are assigned.
What it means
Role escalation is when someone gains a higher role than they were given by exploiting the way roles are assigned. They edit their own role field, accept an invitation meant for someone else, or use a role-management screen that does not check who is calling.
It is a specific form of privilege escalation. The weakness is not in what the higher role can do, but in how a person gets into it. It is one of the most direct ways from an ordinary account to a powerful one, since the role is the permission.
Why it matters
The role is the key to everything else. One successful change turns a free-trial user into an administrator, or a member of one customer's team into the owner of another's account, and every permission check afterwards works exactly as designed, for the wrong person.
It also tends to be quiet. The change looks like a normal profile update or invitation in the log. Without a record of who changed which role, a sudden administrator may only be noticed at the next access review, long after data has been taken.
How it shows up
You meet it in profile update endpoints that accept a role field (mass assignment), in invitation and join links that carry the role in the address, in team admin screens, and in sign-in and SSO setups that map groups to roles. Check who may set a role, and that the check is on the server.
Also test the edges: can a team manager grant a role above their own, can an invitation be reused or edited, can a removed member keep their role, and can a role set for one customer apply in another. These are business-logic flaws, which scanners rarely catch.
Questions people ask
Role escalation, answered
How is role escalation different from privilege escalation?
Role escalation is one way of getting privilege escalation: through the process that assigns roles. Other ways include exploiting a bug in a feature or bypassing a permission check.
What are the common causes?
Update endpoints that accept a role field, invitations whose role can be edited, missing checks on who may grant roles, and group-to-role mappings that trust the wrong source.
Can a user raise their own role?
Only if the server lets them. Whatever the form shows, the server must check who is calling, which role they hold and whether they may grant the one requested.
How should we log role changes?
Record who changed which role, for whom, when and from where, and alert on changes to administrator roles. That record is needed for audits and incident response.
How do we test for it?
Try setting a role through every endpoint that touches a profile or team, edit invitations, and try granting a role above your own. Any success is a finding.
Sources
Where this comes from
Related
Terms that sit next to this one
Privilege escalation
Gaining rights you were never given, sideways or upwards.
Vertical privilege escalation
Climbing to a higher level of access than your account was granted.
Mass assignment
When the fields in a request get written straight onto a record.
RBAC
Permissions attach to roles, and people are given roles.
Business logic flaw
Nothing is technically broken, but your own rules turn against you.
Can an account promote itself?
Role assignment is tested on the running app as a business-logic and cross-account question, and each finding carries the request and response that proved it. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.