Summary

While testing the role management functionality on a target (lets call it target.com ) , I wanted to see how well the application handled privilege changes over time, not just at the moment they were assigned.

At first, I was simply exploring how roles behaved and what each role could do. During this process, I noticed that an admin user could send a request to change their own role. That caught my attention, so I decided to intercept that request and take a closer look at it.

Instead of sending it immediately, I kept it aside and continued testing. Later, after my admin privileges were removed, I went back and replayed the same request.

To my surprise, it worked.

Even though my role had already been downgraded, I was able to restore my admin access using that old request. That's when it became clear that the application was not properly enforcing privilege checks at execution time, which led to a full privilege bypass.

Discovery Process

I started by testing how the application handles roles between different users, especially in cases where privileges are granted and then revoked.

I created two accounts to simulate a real scenario:

• A store owner account
• A second account with admin privileges

After assigning admin access to the second account, I began exploring what actions were available. One thing I noticed was that the admin user could trigger a request to modify their own role.

This is usually a sensitive operation, so I decided to intercept that request using Burp Suite and inspect it more closely.

The request itself looked normal. It included the necessary parameters for updating the role, and nothing suggested that it was tightly bound to the user's current privilege level.

At that point, I started thinking:

If this request was created while I had admin privileges, would it still work after I lose them?

Vulnerability Details

The issue comes from the way the backend handles authorization.

When the request is sent, the server does not properly check whether the user still has the required privileges. Instead, it processes the request as if it were still valid.

This means that:

• A request created with high privileges can still be reused later
• Even if the user's role has already been downgraded

Exploitation

To confirm this behavior, I reproduced the scenario step by step.

I first created two users:

• User A as the store owner
• User B as the test account

User A invited User B to the store and assigned it admin privileges. After accepting the invitation, I logged in as User B.

While logged in, I attempted to change my own role and intercepted the request using Burp Suite. I then sent this request to Repeater and dropped it

Next, I logged back in as User A and downgraded User B from Admin to Staff.

After that, I switched again to User B and went to Burp Repeater. I reused the previously captured request and modified it to set the role back to Admin.

Once I sent the request and refreshed the page, User B had admin privileges again.

Impact

This issue completely breaks the access control model.

Even after an admin's privileges are revoked, they can simply reuse an old request to restore them. This means that privilege removal is not reliable.

An attacker in this position can:

• Regain admin access at any time
• Maintain persistent control over the store
• Perform sensitive actions like:

Managing users and roles

Modifying store settings

In practice, this leads to full control over the store.