CVE-2026-71308: Lemur: Unchecked `replaces[]` lets any user silence notifications and hijack auto-rotation for arbitrary certificates
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 fetchobjects 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 getallpendingreissue, and certificaterotate 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Lemur TLS certificate managementto a version that resolves this vulnerability.Fixed in 1.9.3 - Compensating control
Ensure the victim certificate is excluded from any pending reissue/rotation workflows (e.g., exclude it from get_all_pending_reissue) so certificate_rotate cannot deploy the attacker-controlled replacement to endpoints serving the victim certificate.
- Operational
After upgrading, review for certificates that were marked as “replaced” via unchecked replaces/replacements and verify fleet TLS certificate rotation results are correct (especially where attacker certificates may have been substituted for victim certificates).
Event History
Frequently Asked Questions
Which versions need remediation?
Lemur versions from 0.5.0 through 1.9.2 are affected. Version 1.9.3 fixes the issue by authorizing every certificate referenced as a replacement before mutation.
What access is required to exploit this?
An attacker needs an authenticated Lemur account that is not read-only. They do not need ownership of, or a role on, the certificates they target.
What operations can be abused and what is the impact?
The attacker can submit certificate create, upload, or edit requests containing replacement certificate identifiers. This can mark arbitrary victim certificates as replaced, disable their notifications, remove them from pending reissue processing, and potentially cause rotation to deploy the attacker's certificate to the victim's endpoints.
What should teams do if they are vulnerable?
Upgrade to version 1.9.3. The provided information does not describe an alternative mitigation for deployments that cannot immediately patch.