CVE-2026-71308 in Lemur
Summary
by MITRE • 08/18/2026
Lemur manages TLS certificate creation. From 0.5.0 until 1.9.3, certificate create, upload, and edit requests accepted replaces[] or replacements identifiers that AssociatedCertificateSchema resolved with fetch_objects without a CertificatePermission check. Assigning those objects to Certificate.replaces invoked an append listener that disabled the victim certificate notifications and marked it as replaced. The victim was then excluded from get_all_pending_reissue, and certificate_rotate could deploy the attacker certificate to endpoints serving the victim. An authenticated non-read-only user could target certificates for which the user had no ownership or role, suppress lifecycle automation, and cause fleet-wide TLS disruption or unauthorized substitution. The fix authorizes every referenced replacement certificate before mutation. This issue is fixed in version 1.9.3.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified within Lemur versions ranging from 0.5.0 to 1.9.3 represents a critical authorization bypass that compromises the integrity of TLS certificate management across an organization's infrastructure. Lemur serves as a central platform for managing the lifecycle of Transport Layer Security certificates, including creation, upload, and editing processes. The core flaw resides in how the system handles replacement identifiers during these operations. Specifically, when users submit requests to create, upload, or edit certificates by providing replaces[] or replacements identifiers, the application resolves these references using fetch_objects without performing a necessary CertificatePermission check. This omission allows any authenticated non-read-only user to specify arbitrary certificate objects as replacements for other certificates they do not own and have no administrative role over.
The technical mechanism of this exploitation involves manipulating the internal state of the victim certificate through an append listener triggered during the assignment process. When an attacker assigns a maliciously selected object to Certificate.replaces, the system invokes logic that disables notifications associated with the victim certificate and marks it as replaced. This action effectively removes the legitimate certificate from the get_all_pending_reissue queue, which is responsible for managing automatic renewal processes. Consequently, the automated lifecycle management features are suppressed for the targeted certificate, leaving it in a static or potentially expired state without triggering standard alerting mechanisms that would normally notify administrators of impending expiration or issues.
The operational impact of this vulnerability extends beyond simple denial of service to include severe security risks related to unauthorized substitution and fleet-wide disruption. By suppressing lifecycle automation and disabling notifications, an attacker can cause legitimate certificates to expire unnoticed, leading to widespread TLS disruptions for services relying on those certificates. More critically, the ability to substitute a victim certificate with one controlled by the attacker allows for man-in-the-middle attacks or impersonation of trusted internal or external services. Since the fix authorizes every referenced replacement certificate before mutation is allowed, it confirms that the original design failed to enforce least-privilege principles regarding cross-certificate modifications. This lack of validation enables an authenticated user with minimal privileges to escalate their impact significantly, affecting resources outside their scope of authority and undermining the trust model inherent in PKI deployments managed by Lemur.
To mitigate this risk, organizations must ensure that all instances of Lemur are upgraded to version 1.9.3 or later, where the authorization check for replacement certificates has been implemented. Until the upgrade is performed, administrators should review user roles and permissions to restrict write access to certificate management features only to trusted personnel with explicit ownership or administrative rights over the affected resources. Additionally, monitoring logs for unusual patterns in certificate updates, particularly those involving rapid replacements of high-value certificates by users without corresponding ownership records, can help detect potential exploitation attempts. This vulnerability aligns with CWE-862 Missing Authorization and ATT&CK technique T1078 Valid Accounts, highlighting the importance of rigorous access control checks during state-changing operations within security management tools.