CVE-2026-48508 in Lemur
Summary
by MITRE • 08/18/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Lemur prior to version 1.9.1 represents a critical authorization bypass rooted in improper implementation of access control mechanisms within the application's permission handling logic. Specifically, the flaw resides in the StrictRolePermission and AuthorityCreatorPermission classes located in the lemur/auth/permissions.py module. These components are responsible for enforcing role-based restrictions on sensitive operations such as TLS certificate creation and authority management. Under default configuration conditions where both ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT flags remain unset or explicitly set to False, these permission classes instantiate Flask-Principal Permission objects with an empty list of Need objects. This initialization pattern creates a logical gap that fundamentally undermines the intended security model by allowing any authenticated user to bypass role-based restrictions entirely.
The technical root cause is directly linked to how Flask-Principal evaluates permissions when no specific needs are defined. When a Permission object contains zero Need objects, its allows method returns True for any identity attempting access. Consequently, the authorization gate controlled by these permission classes fails to restrict operations based on user roles. This behavior effectively neutralizes the read-only role designation, granting users with minimal privileges full administrative capabilities over critical infrastructure components. The vulnerability exploits a common misconfiguration pattern where default settings prioritize ease of use or backward compatibility over strict security postures, resulting in an overly permissive access control state that violates the principle of least privilege.
The operational impact of this flaw is severe and multifaceted, affecting multiple endpoints within the Lemur API ecosystem. Authenticated users with read-only roles can exploit this bypass to perform actions intended exclusively for administrators or specialized authority creators. These unauthorized operations include creating root Certificate Authorities via POST /api/1/authorities, uploading arbitrary certificates through POST /api/1/certificates/upload and POST /api/1/pending_certificates//upload, managing notifications via POST /api/1/notifications and PUT or DELETE /api/1/notifications/, and establishing domain entries using POST /api/1/domains. The ability to create root Certificate Authorities allows attackers to issue trusted certificates for any domain, facilitating man-in-the-middle attacks against internal services. Similarly, uploading arbitrary certificates can be leveraged to establish persistent backdoors or impersonate legitimate servers within the network infrastructure.
Furthermore, the capability to edit notifications introduces a significant risk of Server-Side Request Forgery if those notification channels interact with external sinks that process user-supplied data without adequate validation. By crafting malicious notification payloads, an attacker could redirect internal traffic to controlled endpoints, potentially exfiltrating sensitive information or probing internal network services for additional vulnerabilities. The creation of domain entries further expands the attack surface by allowing attackers to register domains within Lemur’s management scope, which may influence routing decisions or certificate issuance policies depending on how downstream systems consume this data. Collectively, these capabilities transform a read-only account into a powerful administrative toolset capable of compromising the integrity and confidentiality of the entire PKI infrastructure managed by Lemur.
This vulnerability aligns with CWE-269 Improper Privilege Management, as it involves granting elevated privileges to users who should be restricted from performing such actions due to their assigned role. It also maps to ATT&CK technique T1078 Valid Accounts, where attackers leverage legitimate credentials and misconfigured permissions to maintain access and escalate privileges within the environment. The flaw highlights the dangers of relying on default configurations that do not enforce strict security boundaries by design. Organizations running versions prior to 1.9.1 are strongly advised to upgrade immediately to mitigate these risks. Additionally, until an upgrade is performed, administrators should explicitly set ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT flags to True in their configuration files to enforce stricter permission checks even if the underlying code flaw persists in older versions. Regular audits of role assignments and API endpoint access logs are recommended to detect any unauthorized usage patterns resulting from this vulnerability.