CVE-2026-71417: Lemur Privilege Escalation Vulnerability

CVE-2026-71417 Overview

CVE-2026-71417 affects Netflix Lemur, an open-source tool that manages Transport Layer Security (TLS) certificate creation and lifecycle. Versions prior to 1.9.3 permit an authenticated non-read-only user to bypass certificate authority permission checks and revoke arbitrary managed certificates. The flaw stems from Lemur tracking certificate identity by internal database rows rather than by the actual CA-side certificate. An attacker uploads a duplicate certificate record matching an existing authority_id and serial, then invokes the revoke endpoint to trigger revocation at the certificate authority. Successful exploitation causes fleet-wide TLS denial of service by revoking certificates the attacker does not own.

Critical Impact
An authenticated user can revoke arbitrary managed TLS certificates at the certificate authority, resulting in fleet-wide TLS denial of service.

Affected Products

Netflix Lemur versions prior to 1.9.3
Deployments exposing POST /api/1/certificates/upload to authenticated users
Deployments exposing PUT /api/1/certificates/<id>/revoke to authenticated users

Discovery Timeline

2026-08-18 - CVE-2026-71417 published to the National Vulnerability Database
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-71417

Vulnerability Analysis

The vulnerability is an authorization flaw classified as [CWE-639] Authorization Bypass Through User-Controlled Key. Lemur enforced CertificatePermission only against the specific database row referenced in a revoke request. It did not verify authorization against the underlying certificate authority or against other rows sharing the same CA-side identity. This design allowed a caller to manufacture a Lemur row whose authorization context they controlled while pointing at a certificate they did not own.

A second safeguard, which prevents revocation of certificates still attached to deployed endpoints, was also bypassed. The attacker-created duplicate row had no cert.endpoints associations, so Lemur treated the certificate as safe to revoke. When the issuer plugin executed the revocation call, it used certificate.body or external_id under the stored authority credentials, causing the CA to revoke the real certificate.

Root Cause

Certificate identity was tracked only by Lemur's internal database row, not by the actual CA-side certificate identifiers. The upload endpoint did not require AuthorityPermission on the referenced authority, and it accepted duplicate (authority_id, serial) pairs. The revoke endpoint authorized the caller against a single Lemur row instead of every row sharing the CA-side identity.

Attack Vector

An authenticated, non-read-only user submits POST /api/1/certificates/upload with a certificate body, authority_id, serial, or external_id that matches an existing record they do not own. Lemur creates a duplicate row without checking authority access or endpoint attachment. The attacker then calls PUT /api/1/certificates/<duplicate_id>/revoke, and the issuer plugin revokes the real certificate at the CA.

text

 Changelog
 =========
 
+1.9.3 - `unreleased`
+~~~~~~~~~~~~~~~~~~~~
+- Fixed arbitrary certificate revocation at the CA (`GHSA-pxmc-2ffp-8j67`_). Certificate identity was tracked
+  only by Lemur's internal database row, not by the actual CA-side certificate. Any authenticated user could
+  upload a duplicate record for a certificate they didn't own (matching an existing ``authority_id`` and
+  ``serial``) and then revoke it via ``PUT /api/1/certificates/<id>/revoke``, causing the CA to revoke the
+  real certificate belonging to another user. ``POST /api/1/certificates/upload`` now requires
+  ``AuthorityPermission`` on the specified authority, and rejects uploads whose ``(authority_id, serial)``
+  pair already matches an existing certificate with a ``409`` response. ``PUT /api/1/certificates/<id>/revoke``
+  now also checks authorization and endpoint attachment against every certificate row sharing
+  ``(authority_id, serial)`` with the one being revoked, not just the row named in the request, closing the
+  gap for any duplicate rows that already exist.

Source: GitHub Commit 851389a

Detection Methods for CVE-2026-71417

Indicators of Compromise

Multiple Lemur certificate rows sharing the same (authority_id, serial) pair in the database.
POST /api/1/certificates/upload requests from users who lack AuthorityPermission on the referenced authority.
Unexpected PUT /api/1/certificates/<id>/revoke calls followed by CA-side revocation events for production certificates.
Revocation activity on certificates with active endpoint deployments still serving traffic.

Detection Strategies

Query the Lemur database for rows grouped by authority_id and serial and alert on any group with a count greater than one.
Correlate Lemur audit logs of upload and revoke operations with CA-side revocation events to identify mismatches in ownership.
Alert on revocation of certificates whose original row has non-empty endpoints while a sibling duplicate row has none.

Monitoring Recommendations

Enable verbose API logging on /api/1/certificates/upload and /api/1/certificates/<id>/revoke and forward events to a centralized log platform.
Monitor Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) feeds from managing certificate authorities for unplanned revocations.
Track TLS handshake failures across the fleet to detect early signs of mass revocation before end-user impact spreads.

How to Mitigate CVE-2026-71417

Immediate Actions Required

Upgrade Lemur to version 1.9.3 or later, which enforces AuthorityPermission on upload and rejects duplicate (authority_id, serial) pairs with a 409 response.
Audit the Lemur database for pre-existing duplicate rows and reconcile ownership before upgrading, since 1.9.3 now checks every matching row during revocation.
Rotate any authority credentials stored in Lemur if unauthorized revocations are suspected.

Patch Information

The fix is included in Lemur v1.9.3 and referenced in GHSA-pxmc-2ffp-8j67. The patch modifies POST /api/1/certificates/upload to require AuthorityPermission and reject duplicate identities. It also modifies PUT /api/1/certificates/<id>/revoke to authorize against every row sharing the (authority_id, serial) pair.

Workarounds

Restrict access to the Lemur API so only trusted operators hold non-read-only roles until the upgrade is complete.
Add a database uniqueness constraint on (authority_id, serial) to block creation of duplicate rows at the storage layer.
Temporarily disable the certificate upload endpoint through reverse-proxy rules if upgrading is not immediately possible.

bash

# Upgrade Lemur to the patched release
pip install --upgrade 'lemur==1.9.3'

# Identify duplicate certificate identities in PostgreSQL before upgrading
psql -d lemur -c "SELECT authority_id, serial, COUNT(*) FROM certificates \
  GROUP BY authority_id, serial HAVING COUNT(*) > 1;"