Description

Lemur manages TLS certificate creation. Prior to 1.9.1, StrictRolePermission and AuthorityCreatorPermission in lemur/auth/permissions.py call flask_principal.Permission.__init__() with zero Need objects when ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT are unset because both flags default to False. Flask-Principal Permission.allows() returns True when self.needs is empty, so the .can() authorization gate permits every authenticated identity, including the read-only role. A read-only user can access POST /api/1/authorities, POST /api/1/certificates/upload, POST /api/1/pending_certificates//upload, POST /api/1/notifications, PUT or DELETE /api/1/notifications/, and POST /api/1/domains to create root Certificate Authorities, upload arbitrary certificates, create or edit notifications that reach an SSRF sink, and create domain entries. Explicitly setting either flag to False continues to opt into the permissive behavior. This issue is fixed in version 1.9.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-18T18:17:41.073Z",
  "pubdate": "2026-08-18T18:17:41.073Z",
  "executiveSummary": "An authorization bypass vulnerability exists in Netflix Lemur prior to version 1.9.1 within the StrictRolePermission and AuthorityCreatorPermission classes located in lemur/auth/permissions.py.\nThe vulnerability arises when the configuration flags ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT default to False or are explicitly set to False, causing the underlying Flask-Principal Permission initialization to receive zero Need objects.\nBecause Flask-Principal's Permission.allows() method evaluates to True when the set of needs is empty, the authorization gate grants access to any authenticated identity, including low-privileged and read-only users.\nAuthenticated attackers possessing only read-only roles can leverage this flaw to perform unauthorized state-changing operations, such as creating root Certificate Authorities, uploading arbitrary certificates, managing notification endpoints that interact with Server-Side Request Forgery (SSRF) sinks, and creating domain entries.\nThe risk implication is severe as it violates the principle of least privilege, allowing privilege escalation from read-only access to administrative capabilities within the certificate management lifecycle.\nExploitation requires network access to the Lemur API and valid credentials with a read-only role, but requires no user interaction.",
  "technicalDetails": "The root cause of the vulnerability resides in lemur/auth/permissions.py within the StrictRolePermission and AuthorityCreatorPermission classes of Lemur prior to version 1.9.1.\nWhen the configuration parameters ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT are unset or default to False, these permission classes invoke flask_principal.Permission.__init__() with an empty collection of Need objects.\nAccording to the design of the Flask-Principal authorization library, the Permission.allows() method returns True when self.needs is empty.\nConsequently, the .can() authorization decorator or gate permits every authenticated identity to bypass security checks, improperly granting administrative privileges to standard or read-only roles.\nThe vulnerable component is the role-based access control mechanism guarding critical API endpoints.\nAffected versions include all Lemur releases prior to version 1.9.1.\nAuthentication is required in the form of a valid user session or token, but privilege requirements are bypassed, allowing read-only users to act as administrators.\nThe vulnerability is exposed over the network via the application's HTTP API endpoints.\nThe attack flow proceeds as follows: 1) An authenticated user with a read-only role sends a restricted API request to endpoints such as POST /api/1/authorities, POST /api/1/certificates/upload, POST /api/1/pending_certificates//upload, POST /api/1/notifications, PUT or DELETE /api/1/notifications/, or POST /api/1/domains. 2) Lemur evaluates the request against StrictRolePermission or AuthorityCreatorPermission. 3) Due to the unpopulated Need collection, the permission check incorrectly evaluates to allowed. 4) The application processes the request, permitting the creation of root Certificate Authorities, the upload of arbitrary certificates, the creation or modification of notifications that reach an SSRF sink, and the creation of unauthorized domain entries.\nPost-exploitation impact includes full compromise of the certificate authority infrastructure, arbitrary certificate issuance, potential internal network scanning or exploitation via SSRF through notification mechanisms, and unauthorized domain management."
}