CVE-2026-71417 in Lemur
Summary
by MITRE • 08/18/2026
Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/certificates/upload allowed a non-read-only user to create a duplicate row using another certificate body, authority_id, serial, or external_id without requiring permission on the underlying authority. PUT /api/1/certificates//revoke authorized the caller against only the selected Lemur row, so the creator of the duplicate bypassed CertificatePermission. The duplicate had no cert.endpoints, which also bypassed the safeguard that prevents revocation of deployed certificates. Issuer plugins then revoked the real CA-side certificate using certificate.body or external_id under the stored authority credentials. An attacker could therefore revoke arbitrary managed certificates and cause fleet-wide TLS denial of service. The fix rejects duplicate authority_id and serial identities, requires authority access on upload, and checks every matching row during revocation. This issue is fixed in version 1.9.3.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Lemur versions prior to 1.9.3 represents a critical failure in identity management and authorization logic within the TLS certificate lifecycle process. Lemur serves as an automation platform for managing digital certificates, acting as an intermediary between organizations and Certificate Authorities. The core flaw stems from insufficient validation during the certificate upload phase via the POST /api/1/certificates/upload endpoint. Specifically, the system failed to enforce uniqueness constraints on critical identifiers such as authority_id, serial number, or external_id when processing uploads by non-read-only users. This oversight allowed an authenticated user with standard privileges to create duplicate database entries for existing certificates without possessing explicit permissions on the underlying Certificate Authority. By exploiting this gap, an attacker could inject a malicious certificate record that mirrored legitimate infrastructure but lacked proper endpoint associations and permission bindings.
The operational impact of this flaw is severe because it directly undermines the integrity of TLS security across an organization's fleet. Once duplicate entries are created, they can be leveraged to bypass critical safeguards designed to prevent accidental or unauthorized revocation of active certificates. Normally, Lemur prevents the revocation of certificates that have associated endpoints, as these represent live services where disruption would cause denial of service. However, because the injected duplicates lacked cert.endpoints, this safeguard was effectively neutralized for those specific records. When an attacker subsequently utilized the PUT /api/1/certificates//revoke endpoint, the system authorized the action based solely on ownership of the duplicate Lemur row rather than verifying permissions against the actual Certificate Authority or checking all matching certificate identities. This logic error allowed the revocation request to propagate to the real CA-side infrastructure using the stored authority credentials associated with the legitimate certificate identity.
The consequence is a remote denial-of-service condition affecting TLS communications across the organization. By triggering the revocation of these manipulated records, an attacker could cause the Certificate Authority to invalidate and revoke genuine, production-grade certificates that were not directly owned or authorized for modification by the attacker. This results in immediate service disruption as clients attempting to connect via HTTPS encounter certificate errors due to revoked trust anchors or leaf certificates. The attack vector is particularly dangerous because it does not require privilege escalation beyond standard user access; instead, it exploits a logical flaw in how identity and permissions are mapped between the Lemur database and external Certificate Authorities. This aligns with CWE-269 Improper Privilege Management, as the system granted actions based on insufficient verification of authority, and can be categorized under ATT&CK technique T1499 Endpoint Denial of Service due to its capacity to disrupt critical network services through certificate invalidation.
To mitigate this vulnerability, organizations must upgrade Lemur to version 1.9.3 or later immediately. The fix addresses the root causes by enforcing strict uniqueness constraints on authority_id and serial numbers during upload operations, thereby preventing the creation of ambiguous duplicate records. Furthermore, the updated logic requires explicit authority access permissions for any certificate upload operation, ensuring that users cannot manipulate certificates associated with authorities they do not control. Additionally, the revocation process has been hardened to check every matching row rather than relying solely on a single database record ID, and it now validates against all potential duplicates before proceeding with CA-side actions. This ensures that even if duplicate entries exist due to legacy data or other anomalies, the system will verify permissions across all relevant identities before executing a revocation command. Maintaining up-to-date software versions is essential for preserving the integrity of automated certificate management workflows and preventing unauthorized disruption of TLS infrastructure.