CVE-2026-71417: Lemur: Any user can revoke arbitrary certificates at the CA by uploading a duplicate record and revoking it
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, authorityid, serial, or externalid 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 externalid 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 authorityid and serial identities, requires authority access on upload, and checks every matching row during revocation. This issue is fixed in version 1.9.3.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.9.3
Event History
Frequently Asked Questions
Who is realistically able to exploit this issue?
Lemur deployments running versions before 1.9.3 are affected when a user has a non-read-only account and can use the certificate upload and revocation API endpoints. The attack does not require permission on the target certificate's underlying certificate authority.
What access and information does an attacker need?
An attacker needs to upload a duplicate certificate record using the target certificate's body, authority ID and serial identity, or external ID, then revoke the duplicate row they created. The issuer plugin can then revoke the real certificate at the CA using stored authority credentials.
What remediation is available?
Upgrade Lemur to version 1.9.3. The fix rejects duplicate authority-and-serial identities, requires authority access when uploading certificates, and checks all matching rows during revocation.
How can we look for signs of exploitation?
Review certificate records and revocation activity for duplicate rows sharing an authority ID and serial identity, certificate body, or external ID with other records. In particular, investigate revocations initiated through duplicate records that have no certificate endpoints.