Description

Lemur manages TLS certificate creation. Prior to 1.9.2, PUT /api/1/roles/ in lemur/roles/views.py:298 authorized updates with RoleMemberPermission(role_id), which allowed either an administrator or any existing member of the target role. The handler passed data["users"] and data["name"] to service.update, allowing a non-admin member to add or remove other users and rename the role. This enabled lateral privilege grants within roles that control certificate and authority access and could deny access by removing legitimate members. The DELETE handler already required admin_permission, confirming that the weaker PUT authorization was inconsistent. The fix applies the same administrator-only requirement to the PUT handler. This issue is fixed in version 1.9.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-08-18T19:16:58.357Z",
  "pubdate": "2026-08-18T19:16:58.357Z",
  "executiveSummary": "An improper authorization vulnerability exists in Lemur prior to version 1.9.2 within the PUT /api/1/roles/ endpoint located in lemur/roles/views.py. This flaw allows any existing member of a target role to update role configurations, bypassing the intended administrator-only restrictions.\nThe vulnerability leads to unauthorized modification of role memberships and role naming conventions, allowing malicious actors or compromised standard accounts to escalate their privileges laterally, grant arbitrary access to certificates and authorities, or perform denial-of-service by evicting legitimate members.\nThe affected product is Lemur prior to version 1.9.2. Exploitation requires authenticated access as an existing member of the target role, enabling unauthorized privilege management and administrative action against sensitive certificate authority infrastructure.",
  "technicalDetails": "The root cause of the vulnerability lies in inconsistent authorization enforcement within the role management logic of lemur/roles/views.py at line 298. Specifically, the PUT handler for /api/1/roles/ was incorrectly secured using RoleMemberPermission(role_id).\nThis authorization check permitted not only administrators but also any standard user who was already a member of the target role to execute update operations. Conversely, the corresponding DELETE handler for the same resource correctly enforced strict administrator-only permissions, highlighting an oversight in access control design.\nDuring exploitation, an authenticated attacker with membership in a target role sends a crafted PUT request to the /api/1/roles/ endpoint. The request payload supplies modified parameters including data['users'] and data['name'].\nThe request handler passes these parameters directly to the service.update function without validating whether the initiating user holds administrative privileges. Consequently, the non-admin member is able to append arbitrary user accounts to the role, remove legitimate members to cause a denial of access, and alter the designated name of the role.\nBecause roles in Lemur control access to critical cryptographic certificates and authorities, this unauthorized modification permits lateral privilege grants. An attacker can inject unauthorized principals into high-value roles, compromising the confidentiality, integrity, and availability of the certificate management infrastructure.\nThe affected component is the PUT /api/1/roles/ handler implemented in lemur/roles/views.py. Affected versions include all deployments of Lemur prior to version 1.9.2. The attack vector is network-based via the application programming interface, requiring valid low-privileged authentication as a baseline prerequisite."
}