Invalid Role Leads to Organization Lockout and Unauthorized API Access

Introduction

In this write-up, I'll explain how I discovered a role validation vulnerability in a web application that allowed an invalid user role to be accepted by the backend, causing organization management issues and unauthorized API access.

Discovery

While testing the application's role management functionality, I noticed that administrators could modify users' roles through an API request.

I intercepted the request using Burp Suite and examined how the server handled role changes.

The request looked like this:

PUT /api/teams/<team_id>/users/<user_id>/roles/default

PUT /api/teams/<team_id>/users/<user_id>/roles/default

The request body contained the target user's ID and the new role:

{
  "userId": "<target_user_id>",
  "role": "5"
}

{
  "userId": "<target_user_id>",
  "role": "5"
}

Instead of rejecting the unsupported role value, the server responded with:

HTTP/2 204 No Content

HTTP/2 204 No Content

This indicated that the request had been accepted.

Testing the Impact

After refreshing the application, I noticed that the affected user's role was displayed as null.

More importantly, the account remained associated with the project, while the organization owner and administrators could no longer modify or remove the affected user through the interface.

I then tested the affected account's access to the application's API.

Although the account had no valid role, it could still access certain team and user-information endpoints directly.

This revealed two problems:

• The backend accepted an unsupported role value.
• API authorization was not consistently enforced for the resulting null-role account.

Steps to reproduce :

1. Create test accounts with Owner, Admin, and Developer roles.
2. Log in as Admin and intercept a request that changes the Developer's role.
3. Modify the role value to "5".
4. Forward the request and observe the 204 No Content response.
5. Refresh the Owner and Admin sessions.
6. Verify that the affected user's role is now null and that the user cannot be removed through the interface.
7. Log in as the affected user and send requests to the relevant team or user-information API endpoints.
8. Verify that the API returns information the account should not be authorized to access.

Conclusion

This finding demonstrated how accepting an unsupported role value can create an inconsistent authorization state, potentially allowing unauthorized API access while preventing administrators from managing the affected user.

Happy hunting .