Summary
The DELETE /api/roles endpoint removes role definitions from the database but does not clean up user assignments that reference the deleted role. This leaves orphaned role IDs in users' info.roles arrays. If permission configurations still reference those role IDs, affected users may retain authorization rights that should have been revoked, leading to inconsistent permission states. The vulnerability has a CVSS score of 2.3 (Low). The provided PoC did not execute successfully due to missing runtime arguments, but the code logic clearly demonstrates the flaw.
Details
Affected Endpoint
- Route:
DELETE /api/roles
- Key files involved:
- Route handler:
server/api/users/index.js (from line 166)
- Business logic:
server/runtime/users/index.js, line 143
- Database operations:
server/runtime/users/usrstorage.js, lines 236–237
- Permission checks:
server/runtime/index.js, line 669
Root Cause
When an administrator deletes a role via DELETE /api/roles, the system only executes DELETE FROM roles WHERE name = ? to remove the role definition. It does not iterate through the user table to remove the corresponding role ID from each user's info.roles array. Subsequent permission checks (e.g., userPermission.info.roles.some()) verify whether a user's role array contains any of the allowed role IDs. If a deleted role ID remains present in the user's assignment and the permission policy has not been updated, the user may continue to possess the original role's privileges.
Suggested Fix
When a role is deleted, the system should also update all users to remove the deleted role ID from their info.roles arrays. Alternatively, foreign key constraints with cascading actions could enforce data consistency.
Impact
The business logic flaw can lead to the following security issues:
- Residual Privilege and Unauthorized Access: If a deleted role is still referenced in permission configurations, users holding that role ID may continue to access restricted resources or functions, resulting in unauthorized actions.
- Management Confusion and Audit Failure: Administrators may believe that a role and its associated rights have been completely removed, while in reality some users still retain those rights. This undermines access control management and complicates security audits.
- Compliance Risks: In environments requiring strict access control and periodic reviews, such inconsistent permission states may violate the principle of least privilege and relevant audit requirements.
Although the CVSS score is low, for systems that depend on precise role-based access control, this issue could be exploited to maintain unauthorized access over time. Remediation is recommended to ensure role deletion fully revokes all related permissions.
Summary
The
DELETE /api/rolesendpoint removes role definitions from the database but does not clean up user assignments that reference the deleted role. This leaves orphaned role IDs in users'info.rolesarrays. If permission configurations still reference those role IDs, affected users may retain authorization rights that should have been revoked, leading to inconsistent permission states. The vulnerability has a CVSS score of 2.3 (Low). The provided PoC did not execute successfully due to missing runtime arguments, but the code logic clearly demonstrates the flaw.Details
Affected Endpoint
DELETE /api/rolesserver/api/users/index.js(from line 166)server/runtime/users/index.js, line 143server/runtime/users/usrstorage.js, lines 236–237server/runtime/index.js, line 669Root Cause
When an administrator deletes a role via
DELETE /api/roles, the system only executesDELETE FROM roles WHERE name = ?to remove the role definition. It does not iterate through the user table to remove the corresponding role ID from each user'sinfo.rolesarray. Subsequent permission checks (e.g.,userPermission.info.roles.some()) verify whether a user's role array contains any of the allowed role IDs. If a deleted role ID remains present in the user's assignment and the permission policy has not been updated, the user may continue to possess the original role's privileges.Suggested Fix
When a role is deleted, the system should also update all users to remove the deleted role ID from their
info.rolesarrays. Alternatively, foreign key constraints with cascading actions could enforce data consistency.Impact
The business logic flaw can lead to the following security issues:
Although the CVSS score is low, for systems that depend on precise role-based access control, this issue could be exploited to maintain unauthorized access over time. Remediation is recommended to ensure role deletion fully revokes all related permissions.