CVE-2026-71417

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.

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.

Summary

Repo under test: https://github.com/Netflix/lemur

PUT /api/1/certificates/<id>/revoke authorizes the caller against the Lemur database row (creator == current user, or CertificatePermission over the row's roles) rather than the underlying CA-side certificate identity. Separately, POST /api/1/certificates/upload lets any user passing StrictRolePermission create a new Certificate row while freely supplying body, authority (resolved by id/name with no AuthorityPermission check) and external_id; there is no uniqueness constraint on body, serial, or external_id.

An attacker can therefore read a target certificate's public body, authority.id, and external_id via GET /certificates/<id>, upload a duplicate row, and revoke that duplicate. The creator-bypass skips CertificatePermission, the empty-endpoints check passes because the duplicate has none, and service.revoke() then revokes at the CA using the attacker-supplied body (ACME) or external_id (DigiCert/Entrust/Google CA/CFSSL) under the authority's stored CA credentials — revoking the real production certificate.

Affected route

POST /api/1/certificates/upload → PUT /api/1/certificates/<dup_id>/revoke

Affected code

• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates upload; no AuthorityPermission check
• lemur/certificates/schemas.py:391 — CertificateUploadInputSchema accepts caller-supplied authority and external_id
• lemur/schemas.py:107 — AssociatedAuthoritySchema resolves any authority by id/name with no permission check
• lemur/certificates/service.py:489 — upload() binds the caller-supplied authority onto the new row
• lemur/certificates/models.py:119 — only name is unique; body/serial/external_id are not, and get_or_increase_name() auto-suffixes on collision
• lemur/certificates/views.py:1677 — if g.current_user != cert.user: ... CertificatePermission ... — creator of the duplicate row bypasses the owner check
• lemur/certificates/views.py:1687 — if cert.endpoints: ... — duplicate row has no endpoints, so the deployed-cert safeguard is bypassed
• lemur/certificates/service.py:1120 — plugin = plugins.get(certificate.authority.plugin_name); plugin.revoke_certificate(certificate, reason)
• lemur/plugins/lemur_acme/acme_handlers.py:268 — ACME revokes by certificate.body
• lemur/plugins/lemur_digicert/plugin.py:477, lemur/plugins/lemur_entrust/plugin.py:321 — commercial CAs revoke by certificate.external_id
• lemur/certificates/schemas.py:290 — CertificateOutputSchema exposes external_id, body, authority to any authenticated user

Impact

A low-privileged authenticated insider (or holder of a stolen non-admin token/API key) can revoke any certificate managed by Lemur — including high-value certificates they do not own and certificates currently attached to live endpoints — directly at the issuing CA. Iterating over `GET…

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.

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.

Summary

Repo under test: https://github.com/Netflix/lemur

PUT /api/1/certificates/<id>/revoke authorizes the caller against the Lemur database row (creator == current user, or CertificatePermission over the row's roles) rather than the underlying CA-side certificate identity. Separately, POST /api/1/certificates/upload lets any user passing StrictRolePermission create a new Certificate row while freely supplying body, authority (resolved by id/name with no AuthorityPermission check) and external_id; there is no uniqueness constraint on body, serial, or external_id.

An attacker can therefore read a target certificate's public body, authority.id, and external_id via GET /certificates/<id>, upload a duplicate row, and revoke that duplicate. The creator-bypass skips CertificatePermission, the empty-endpoints check passes because the duplicate has none, and service.revoke() then revokes at the CA using the attacker-supplied body (ACME) or external_id (DigiCert/Entrust/Google CA/CFSSL) under the authority's stored CA credentials — revoking the real production certificate.

Affected route

POST /api/1/certificates/upload → PUT /api/1/certificates/<dup_id>/revoke

Affected code

• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates upload; no AuthorityPermission check
• lemur/certificates/schemas.py:391 — CertificateUploadInputSchema accepts caller-supplied authority and external_id
• lemur/schemas.py:107 — AssociatedAuthoritySchema resolves any authority by id/name with no permission check
• lemur/certificates/service.py:489 — upload() binds the caller-supplied authority onto the new row
• lemur/certificates/models.py:119 — only name is unique; body/serial/external_id are not, and get_or_increase_name() auto-suffixes on collision
• lemur/certificates/views.py:1677 — if g.current_user != cert.user: ... CertificatePermission ... — creator of the duplicate row bypasses the owner check
• lemur/certificates/views.py:1687 — if cert.endpoints: ... — duplicate row has no endpoints, so the deployed-cert safeguard is bypassed
• lemur/certificates/service.py:1120 — plugin = plugins.get(certificate.authority.plugin_name); plugin.revoke_certificate(certificate, reason)
• lemur/plugins/lemur_acme/acme_handlers.py:268 — ACME revokes by certificate.body
• lemur/plugins/lemur_digicert/plugin.py:477, lemur/plugins/lemur_entrust/plugin.py:321 — commercial CAs revoke by certificate.external_id
• lemur/certificates/schemas.py:290 — CertificateOutputSchema exposes external_id, body, authority to any authenticated user

Impact

A low-privileged authenticated insider (or holder of a stolen non-admin token/API key) can revoke any certificate managed by Lemur — including high-value certificates they do not own and certificates currently attached to live endpoints — directly at the issuing CA. Iterating over `GET…

Summary

Repo under test: https://github.com/Netflix/lemur

PUT /api/1/certificates/<id>/revoke authorizes the caller against the Lemur database row (creator == current user, or CertificatePermission over the row's roles) rather than the underlying CA-side certificate identity. Separately, POST /api/1/certificates/upload lets any user passing StrictRolePermission create a new Certificate row while freely supplying body, authority (resolved by id/name with no AuthorityPermission check) and external_id; there is no uniqueness constraint on body, serial, or external_id.

An attacker can therefore read a target certificate's public body, authority.id, and external_id via GET /certificates/<id>, upload a duplicate row, and revoke that duplicate. The creator-bypass skips CertificatePermission, the empty-endpoints check passes because the duplicate has none, and service.revoke() then revokes at the CA using the attacker-supplied body (ACME) or external_id (DigiCert/Entrust/Google CA/CFSSL) under the authority's stored CA credentials — revoking the real production certificate.

Affected route

POST /api/1/certificates/upload → PUT /api/1/certificates/<dup_id>/revoke

Affected code

• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates upload; no AuthorityPermission check
• lemur/certificates/schemas.py:391 — CertificateUploadInputSchema accepts caller-supplied authority and external_id
• lemur/schemas.py:107 — AssociatedAuthoritySchema resolves any authority by id/name with no permission check
• lemur/certificates/service.py:489 — upload() binds the caller-supplied authority onto the new row
• lemur/certificates/models.py:119 — only name is unique; body/serial/external_id are not, and get_or_increase_name() auto-suffixes on collision
• lemur/certificates/views.py:1677 — if g.current_user != cert.user: ... CertificatePermission ... — creator of the duplicate row bypasses the owner check
• lemur/certificates/views.py:1687 — if cert.endpoints: ... — duplicate row has no endpoints, so the deployed-cert safeguard is bypassed
• lemur/certificates/service.py:1120 — plugin = plugins.get(certificate.authority.plugin_name); plugin.revoke_certificate(certificate, reason)
• lemur/plugins/lemur_acme/acme_handlers.py:268 — ACME revokes by certificate.body
• lemur/plugins/lemur_digicert/plugin.py:477, lemur/plugins/lemur_entrust/plugin.py:321 — commercial CAs revoke by certificate.external_id
• lemur/certificates/schemas.py:290 — CertificateOutputSchema exposes external_id, body, authority to any authenticated user

Impact

A low-privileged authenticated insider (or holder of a stolen non-admin token/API key) can revoke any certificate managed by Lemur — including high-value certificates they do not own and certificates currently attached to live endpoints — directly at the issuing CA. Iterating over `GET…