Change Your Role, or Change the Role?

Hello everyone

This time, I'd like to share a privilege escalation vulnerability I discovered during a private bug bounty engagement.

What I liked about this bug is that it didn't start with some fancy exploit or a hidden endpoint. It started with something we've all seen before: a few disabled checkboxes.

Sometimes those little UI restrictions hide much bigger backend problems.

Let's see how a simple "You can't edit this permission" message turned into a privilege escalation by modifying the authorization model itself.

Understanding the Application

Before jumping into testing, I always like to understand how the application is structured.

The target was an enterprise SaaS platform where multiple organizations could manage their own users.

Each organization had its own members, roles, and permissions, with Role-Based Access Control (RBAC) used to determine what each user was allowed to do. Great, now let's start hacking.

Testing the Obvious

Whenever I test an application, Broken Access Control is usually one of the first things I look at, so I opened a new tab in Pwnfox and invited my other email as a low-privilege user. My first idea was simple: can I promote my own account? So I tried a normal privilege escalation by changing my role to a higher role, but as expected, I got a 403 Forbidden response

So I guess it is secure, right? …Well, not exactly.

Something Felt Off

After the first try, I decided to continue testing other functions, and I came across a page used to manage the permissions of every role, but something felt wrong. Even administrators weren't allowed to modify these permissions. The UI disabled every control and displayed a warning saying that user management permissions cannot be customized.

So I decided to give it a closer look.

Was this enforced by the backend… or only by the UI?

Letting the UI Do the Work

At this point, I couldn't simply intercept the request because there wasn't one.

The UI wouldn't let anyone submit it — not even administrators.

That left me with two options:

• Reverse engineer the API from the JavaScript files.
• Or convince the frontend to send the request for me.

As you can see, the buttons are already there, but they are disabled, so I opened the dev tools in the browser and searched for the checkbox, and I found the disabled attribute.

I removed it, and now I can use the checkbox.

I did the same with the Save Changesbutton, and once I clicked on it, a confirmation window popped up.

I clicked Save Changes, confirmed the action, and waited for the response.

Wait… It Actually Worked?

The request was accepted.

The supposedly immutable permission had just been modified.

At that moment, it became clear that the restriction existed only in the frontend.

From a UI Restriction to Privilege Escalation

Earlier, changing my own role returned 403 Forbidden.

But now, I didn't need to change my role anymore.

I simply changed the permissions of the role already assigned to my account.

The end result was exactly the same.

Instead of changing who I was, I changed what my role was allowed to do.

The Final Step

All that was left was writing the report.

The report was eventually triaged and accepted as Medium severity.

It all started with a few disabled checkboxes.

Sometimes, you don't need to change your role.

You only need to change what your role means.

That's it for today's write-up. See you next time!