The PUT /api/1/roles/<id> handler in Lemur improperly authorizes role membership modifications by allowing any member of the role to update the role's users and name. The permission check uses RoleMemberPermission(role_id), which grants access if the user is either an admin or a member of the role. This permits non-admin role members to rewrite the membership list and rename the role. The DELETE handler on the same resource correctly requires admin permissions, highlighting an authorization inconsistency. The vulnerability enables lateral privilege escalation within roles by allowing members to add or remove users arbitrarily. Direct promotion to admin via renaming is blocked by unique constraints and strict admin checks.

An attacker who is a member of a non-admin role can add arbitrary users to that role, granting them the same privileges and access as other role members. They can also remove users from the role, potentially disrupting access for legitimate users. Additionally, the attacker can rename the role, although renaming to 'admin' or equivalent to gain admin privileges is prevented by database constraints and admin checks. This vulnerability can lead to unauthorized privilege escalation and availability impacts within Lemur deployments that delegate authority to non-admin roles.

A fix is available by adding an admin permission requirement to the PUT /api/1/roles/<id> handler, mirroring the existing restriction on DELETE. Specifically, the PUT method should be decorated with @admin_permission.require(http_exception=403) to restrict role modifications to admins only. If selective delegation of role management is desired, it should be implemented with a dedicated permission model reflecting role ownership rather than membership, and the role name field should be excluded from delegated updates. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance.