Summary
ELADMIN's role management endpoint applies an incomplete authorization check when updating role menus. A logged-in non-admin user with the delegated roles:edit permission may modify its own role and assign arbitrary menu identifiers, potentially escalating privileges or gaining unauthorized access.
ELADMIN's role management endpoint applies an incomplete authorization check when updating role menus. A logged-in non-admin user with the delegated roles:edit permission may modify its own role and assign arbitrary menu identifiers, potentially escalating privileges or gaining unauthorized access.
Affected context
The vulnerability occurs in ELADMIN (eladmin-mp) deployments through the role management endpoint PUT /api/roles/menu, handled by RoleController.updateRoleMenu. It becomes risky when a non-admin account has the roles:edit permission and the application relies only on role-level comparison without validating the requested menu set or blocking self-modification.
The vulnerability occurs in ELADMIN (eladmin-mp) deployments through the role management endpoint PUT /api/roles/menu, handled by RoleController.updateRoleMenu. It becomes risky when a non-admin account has the roles:edit permission and the application relies only on role-level comparison without validating the requested menu set or blocking self-modification.
Exploit preconditions
- Attack surface: Authenticated role-management API
- Required access: A logged-in account whose role includes the delegated
roles:editpermission - Trigger point: Submission of a role-menu update request containing the caller's own role identifier
- Why exploitation is possible: Authorization checks compare role levels but do not adequately constrain the target role, validate assigned menus, or prevent self-modification
- Attack surface: Authenticated role-management API
- Required access: A logged-in account whose role includes the delegated
roles:editpermission - Trigger point: Submission of a role-menu update request containing the caller's own role identifier
- Why exploitation is possible: Authorization checks compare role levels but do not adequately constrain the target role, validate assigned menus, or prevent self-modification
Why this happens
The underlying flaw is an incomplete authorization design. The endpoint checks whether the target role's level is compatible with the caller's minimum level, but it does not enforce object-level ownership boundaries or verify that each requested menu is permitted for the caller to grant. This maps to CWE-284: Improper Access Control, where access decisions fail to sufficiently restrict an authenticated subject's ability to modify protected authorization data.
The underlying flaw is an incomplete authorization design. The endpoint checks whether the target role's level is compatible with the caller's minimum level, but it does not enforce object-level ownership boundaries or verify that each requested menu is permitted for the caller to grant. This maps to CWE-284: Improper Access Control, where access decisions fail to sufficiently restrict an authenticated subject's ability to modify protected authorization data.
Potential impact
- A user may modify its own role permissions
- Unauthorized menus may be assigned to a role
- The account may gain access to administrative functions
- Authorization boundaries between delegated users and administrators could be weakened
- Subsequent misuse may expose or alter protected application data
- A user may modify its own role permissions
- Unauthorized menus may be assigned to a role
- The account may gain access to administrative functions
- Authorization boundaries between delegated users and administrators could be weakened
- Subsequent misuse may expose or alter protected application data
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the role and permission object level rather than relying on role-level comparisons alone.
Common defensive patterns include:
- Preventing delegated users from modifying their own effective role or permissions
- Validating every requested menu against an explicitly permitted grant set
- Applying server-side allowlists for assignable menus and protected administrative capabilities
- Separating permission-management authority from general role-editing privileges
- Requiring stronger privilege or independent approval for authorization changes
- Logging and reviewing role-menu modifications, with safeguards against unauthorized bulk changes
Mitigation generally focuses on enforcing authorization at the role and permission object level rather than relying on role-level comparisons alone.
Common defensive patterns include:
- Preventing delegated users from modifying their own effective role or permissions
- Validating every requested menu against an explicitly permitted grant set
- Applying server-side allowlists for assignable menus and protected administrative capabilities
- Separating permission-management authority from general role-editing privileges
- Requiring stronger privilege or independent approval for authorization changes
- Logging and reviewing role-menu modifications, with safeguards against unauthorized bulk changes
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis and code review checks for authorization decisions based only on numeric role levels
- Review of endpoints that accept user-controlled role, user, permission, or menu identifiers
- Tests confirming that users cannot alter their own effective privileges
- Negative authorization tests for assigning permissions outside the caller's grant scope
- API policy enforcement requiring object-level authorization and protected-resource checks
- Audit monitoring for unexpected role-menu changes or privilege increases
Organizations can identify similar issues through:
- Static analysis and code review checks for authorization decisions based only on numeric role levels
- Review of endpoints that accept user-controlled role, user, permission, or menu identifiers
- Tests confirming that users cannot alter their own effective privileges
- Negative authorization tests for assigning permissions outside the caller's grant scope
- API policy enforcement requiring object-level authorization and protected-resource checks
- Audit monitoring for unexpected role-menu changes or privilege increases
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| github. | github.com/ |
