CVE-2026-71308: Missing Authorization and Lifecycle Hijacking in Netflix Lemur

Netflix Lemur is an enterprise-grade certificate management framework designed to orchestrate the lifecycle of Transport Layer Security (TLS) and Secure Sockets Layer (SSL) certificates. It acts as a central repository and broker, coordinating certificate generation, renewal, and deployment across diverse infrastructure providers, including cloud platforms like Amazon Web Services (AWS) and container orchestration engines such as Kubernetes.

Because Lemur possesses administrative privileges to integrate with external load balancers, content delivery networks (CDNs), and keystores, it represents a high-value target for security architecture. Any vulnerability within its API endpoints can expose wide-ranging downstream infrastructure to unauthorized modifications.

CVE-2026-71308 describes a severe missing authorization flaw in Lemur's certificate-associated endpoints. In versions from 0.5.0 up to (but excluding) 1.9.3, the system fails to validate whether a user requesting a certificate creation, upload, or modification has permissions to modify certificates referenced in the replaces or replacements arrays. This lack of authorization allows authenticated users to hijack the rotation and notification lifecycles of any arbitrary certificate managed within the system.

The core of the vulnerability lies in Lemur's processing of relationship models during deserialization. When a certificate is uploaded, created, or updated via API requests, the input is processed by Lemur's marshmallow schemas, specifically the schemas defining certificate associations. If the payload contains the replaces or replacements parameters, Lemur uses a generic utility called fetch_objects to query and instantiate corresponding Certificate SQLAlchemy database records.

Historically, Lemur did not verify if the requesting user owned, created, or possessed the necessary role permissions (CertificatePermission) for the target certificates resolved via fetch_objects. This omission allowed any authenticated, non-read-only user to link their newly created certificate to an arbitrary, pre-existing certificate in the system.

Once the relationship is established, SQLAlchemy triggers an append event listener bound to the Certificate.replaces relationship. This database event automatically executes several mutations on the target certificate: it toggles the notify parameter to False to silence upcoming expiration alerts and marks the certificate as replaced. This prevents administrators from receiving warnings when the victim certificate is near expiration, while preparing the platform to deploy the attacker-controlled certificate in its place during subsequent scheduled background rotation tasks.

The resolution to CVE-2026-71308 is implemented in commit 286874535160952143b0afe2d356642669f9d4c6. The patch introduces an authorization helper, authorize_certificate_replacement, within lemur/certificates/service.py and integrates it into the relevant endpoints in lemur/certificates/views.py.

Before the patch, endpoints like /api/1/certificates/upload did not evaluate permissions for the certificate IDs passed in the replaces list. The following diff highlights the introduction of this authorization check:

# lemur/certificates/service.py
+def authorize_certificate_replacement(certificates, current_user):
+    """
+    Ensures the current user owns, holds a role on, or is the creator of every certificate
+    being marked as replaced. Marking a certificate as replaced silences its expiration
+    notifications and retargets its rotation, so it requires the same authorization as
+    revoking or editing that certificate directly.
+    """
+    for cert in certificates:
+        if current_user == cert.user:
+            continue
+
+        owner_role = role_service.get_by_name(cert.owner)
+        permission = CertificatePermission(owner_role, [r.name for r in cert.roles])
+
+        if not permission.can():
+            raise UnauthorizedError(
+                f"You are not authorized to replace certificate: {cert.name}"
+            )

The check verifies whether the current user is the owner, or if their roles match the certificate's permission policies. The view handlers in lemur/certificates/views.py are patched to execute this function before saving state changes:

# lemur/certificates/views.py
@@ -651,6 +653,12 @@ def post(self, data=None):
         if not StrictRolePermission().can():
             return dict(message="You are not authorized to upload a certificate."), 403
 
+        if data.get("replaces"):
+            try:
+                service.authorize_certificate_replacement(data["replaces"], g.current_user)
+            except UnauthorizedError as e:
+                return dict(message=str(e)), 403

This ensures that if the input payload attempts to associate a new certificate as a replacement for an existing one, the operation fails immediately with a 403 Forbidden unless the user holds adequate privileges over the target certificate.

Exploitation of CVE-2026-71308 requires an attacker to possess network access to the Lemur instance and valid credentials belonging to any non-read-only role. The attack proceeds through discrete phases, beginning with active reconnaissance of vulnerable targets via the Lemur API.

First, the attacker enumerates active certificates. Although default read permissions might restrict write access, standard users typically have read access to metadata. The attacker identifies the ID of a target certificate (e.g., 9999).

Next, the attacker constructs a payload representing a new certificate. This certificate may contain an attacker-controlled private key. The attacker calls the upload or creation endpoint, appending the targeted certificate ID into the replaces field.

Once submitted, the database updates immediately. The original certificate is flagged as replaced, its notifications are silenced, and when Lemur's cron-based automation cycles execute certificate_rotate, it automatically pushes the attacker's newly associated certificate to the integrated AWS ELBs, CloudFront distributions, or Kubernetes secrets previously tied to the original certificate. This results in direct traffic interception.

The security impact of CVE-2026-71308 is classified as High, with a CVSS v3.1 base score of 8.1. The attack complexity is Low since exploitation does not depend on complex timing or environment states. Because Lemur is designed to automate certificate rotations to critical entry points, the downstream consequences are far-reaching.

By successfully mapping a malicious or unapproved certificate to an active deployment target, an attacker achieves complete control over TLS endpoints. This allows the interception and decryption of encrypted user traffic (Man-in-the-Middle), leading to the exposure of credentials, session tokens, and sensitive data.

Furthermore, silencing expiration notifications for critical endpoints compromises availability. If the original certificate is replaced by an invalid or unapproved certificate, production services may experience complete denial of service when client browsers or systems reject the untrusted or misconfigured certificate. The lack of auditing before version 1.9.3 makes identifying such modifications difficult without manual database verification.

The definitive remediation for CVE-2026-71308 is updating Netflix Lemur to version 1.9.3 or later. This version enforces complete role-based and ownership-based validation during certificate replacement processing, terminating unauthorized attempts prior to database persistence.

For environments unable to deploy the patch immediately, the following temporary mitigations are recommended:

1. Restrict API access to non-administrative users. Revoke write permissions (POST, PUT) from user roles that do not strictly require certificate issuance or upload capabilities.

2. Monitor server logs for incoming requests to /api/1/certificates/upload or /api/1/certificates/<id> containing the replaces JSON field. Flag and investigate any requests where the submitting identity does not match the recorded owner of the referenced certificate.

3. Perform regular database integrity checks. Administrators can execute queries to detect discrepancies where the creator of a replacing certificate differs from the owner of the replaced certificate, indicating a potential compromise.