Summary
A user with the USER_ADMIN role can update the role of an existing SUPER_ADMIN account to USER or another non-super-admin role.
The current role update logic blocks non-SUPER_ADMIN users from assigning the SUPER_ADMIN role, but it does not check whether the target user already has SUPER_ADMIN. As a result, USER_ADMIN can remove super-admin privileges from another account through the admin user role update API.
Steps To Reproduce
- Prepare two platform users:
- Actor user: has
USER_ADMIN
- Target user: has
SUPER_ADMIN
- Sign in as the actor user.
- Call
PUT /api/v1/admin/users/{targetUserId}/role with:
- Observe that the request succeeds.
- Check the target user's platform roles. The target user no longer has
SUPER_ADMIN.
Expected Behavior
Only users with SUPER_ADMIN should be allowed to mutate any SUPER_ADMIN role state.
A USER_ADMIN should not be able to:
- assign
SUPER_ADMIN;
- remove
SUPER_ADMIN;
- replace an existing
SUPER_ADMIN role with USER or another role.
USER_ADMIN should still be able to manage ordinary non-SUPER_ADMIN users.
Environment
Current mainline backend behavior.
Affected area:
- Admin user management
- Platform role mutation
- RBAC authorization checks
PUT /api/v1/admin/users/{userId}/role
API Contract Impact
No API contract change is expected.
The existing endpoint and request body can remain unchanged. The fix should only tighten backend authorization behavior and return a forbidden error when a non-SUPER_ADMIN actor attempts to mutate a target user who currently has SUPER_ADMIN.
Implementation Scope
- Update backend role mutation authorization.
- Detect whether the target user currently has
SUPER_ADMIN.
- Require actor
SUPER_ADMIN when the requested role is SUPER_ADMIN or the target user currently has SUPER_ADMIN.
- Add regression test coverage for the demotion path.
- No frontend or OpenAPI generated type changes are expected.
Acceptance Criteria
USER_ADMIN cannot assign SUPER_ADMIN.USER_ADMIN cannot downgrade or replace the role of an existing SUPER_ADMIN.SUPER_ADMIN can still manage SUPER_ADMIN role mutations.USER_ADMIN can still manage ordinary non-SUPER_ADMIN users.- Rejected role mutation does not delete or alter existing role bindings.
Summary
A user with the
USER_ADMINrole can update the role of an existingSUPER_ADMINaccount toUSERor another non-super-admin role.The current role update logic blocks non-
SUPER_ADMINusers from assigning theSUPER_ADMINrole, but it does not check whether the target user already hasSUPER_ADMIN. As a result,USER_ADMINcan remove super-admin privileges from another account through the admin user role update API.Steps To Reproduce
USER_ADMINSUPER_ADMINPUT /api/v1/admin/users/{targetUserId}/rolewith:{ "role": "USER" }SUPER_ADMIN.Expected Behavior
Only users with
SUPER_ADMINshould be allowed to mutate anySUPER_ADMINrole state.A
USER_ADMINshould not be able to:SUPER_ADMIN;SUPER_ADMIN;SUPER_ADMINrole withUSERor another role.USER_ADMINshould still be able to manage ordinary non-SUPER_ADMINusers.Environment
Current mainline backend behavior.
Affected area:
PUT /api/v1/admin/users/{userId}/roleAPI Contract Impact
No API contract change is expected.
The existing endpoint and request body can remain unchanged. The fix should only tighten backend authorization behavior and return a forbidden error when a non-
SUPER_ADMINactor attempts to mutate a target user who currently hasSUPER_ADMIN.Implementation Scope
SUPER_ADMIN.SUPER_ADMINwhen the requested role isSUPER_ADMINor the target user currently hasSUPER_ADMIN.Acceptance Criteria
USER_ADMINcannot assignSUPER_ADMIN.USER_ADMINcannot downgrade or replace the role of an existingSUPER_ADMIN.SUPER_ADMINcan still manageSUPER_ADMINrole mutations.USER_ADMINcan still manage ordinary non-SUPER_ADMINusers.