CVE-2026-71317: Missing Authorization in Netflix Lemur Allows Unauthorized Subordinate CA Creation

Netflix Lemur functions as an orchestration and management engine for Public Key Infrastructure (PKI) certificates across enterprise networks. To simplify administrative operations and support developer workflows, Lemur includes a self-service model that allows non-privileged users to request and create new Certificate Authorities (CAs). This capability is governed by the ADMIN_ONLY_AUTHORITY_CREATION configuration setting, which, when configured to False, permits any standard authenticated user to register and generate CA objects.

Under normal operations, a subordinate CA (sub-CA) must be chained to an existing root or intermediate CA. When creating a sub-CA, the user specifies a target parent authority from Lemur's inventory. The API endpoint handling these creation requests is located at POST /api/1/authorities.

The vulnerability, identified as CVE-2026-71317 (GHSA-g7p5-89mh-248h), resides within this endpoint. The endpoint fails to verify if the requesting authenticated user has been granted appropriate operational or administrative rights (AuthorityPermission) over the requested parent CA. Consequently, standard authenticated accounts can chain newly created sub-CAs to highly sensitive root CAs, bypassing the system's intended logical isolation and access control policies.

The root cause of CVE-2026-71317 is a Broken Object-Level Authorization (BOLA) flaw in the endpoint controller within lemur/authorities/views.py. When a POST request is processed by the AuthoritiesList resource, Lemur validates global privileges using AuthorityCreatorPermission and StrictRolePermission. These checks ensure that the user is permitted to create CA objects in general, which is satisfied by any authenticated user if self-service creation is enabled.

To parse the incoming JSON payload, the application employs Marshmallow serialization schemas. The parent attribute of the payload is resolved using the AssociatedAuthoritySchema. This schema executes database lookups (e.g., fetch_objects) to retrieve the underlying database object for the parent authority based on user-provided identifier values.

Crucially, prior to version 1.9.3, once the parent object was resolved, the controller failed to execute an object-level permission check. The system assumed that the successful retrieval of the parent CA meant the operation could proceed. It did not evaluate whether the user belonged to the administrative roles linked to that specific parent CA resource.

After resolving the parent object, the application hands control over to the configured signing plugin (typically cryptography-issuer). The cryptographic engine retrieves the parent authority's stored private key material (authority_certificate.private_key) and uses it to sign the newly requested subordinate CA certificate. The lack of validation on the parent CA allows standard users to coerce the backend into performing administrative signing operations using restricted cryptographic keys.

In vulnerable versions of Lemur (prior to 1.9.3), the post method of the AuthoritiesList class inside lemur/authorities/views.py only validated global creator permissions before invoking the CA generation workflow. The vulnerable logic did not examine the relationship between the active user and the retrieved parent CA.

# Vulnerable implementation in lemur/authorities/views.py
def post(self, data=None):
    permission = AuthorityCreatorPermission()
    if not permission.can() or not StrictRolePermission().can():
        return dict(message="You are not allowed to create a new authority."), 403
 
    # Vulnerability: The parent authority is resolved inside `data` (via schemas)
    # but no authority-specific permissions are evaluated before creation
    new_authority = manager.create(**data)

The official fix in version 1.9.3 (commit 8669011203ca3dd89d9e39bab9ef6850eca723f9) resolves the issue by intercepting the parsed parent CA within the post method and verifying the caller's rights against the parent's assigned roles.

# Patched implementation in lemur/authorities/views.py
def post(self, data=None):
    permission = AuthorityCreatorPermission()
    if not permission.can() or not StrictRolePermission().can():
        return dict(message="You are not allowed to create a new authority."), 403
 
    # Patched: Retrieve and validate parent authority permissions
    parent = data.get("parent")
    if parent:
        parent_roles = [x.name for x in parent.roles]
        if not AuthorityPermission(parent.id, parent_roles).can():
            return dict(message="You are not authorized to use the specified parent authority."), 403
 
    if not validators.is_valid_owner(data["owner"]):
        return dict(message=f"Invalid owner: check if {data['owner']} is a valid group email."), 412

This patch successfully mitigates the vulnerability by ensuring that every sub-CA creation request undergoes a secondary, object-specific check. If the user does not possess administrative or operational roles associated with the parent CA, the controller terminates the execution path and returns an HTTP 403 Forbidden status code, blocking the cryptographic issuer from signing the certificate.

To exploit this vulnerability, an attacker must have valid, non-privileged authentication credentials to a Lemur instance that has self-service CA creation enabled (ADMIN_ONLY_AUTHORITY_CREATION = False). The attacker begins by identifying or predicting the ID of an internal Root or parent CA managed by the target Lemur instance (such as the default root authority, which often holds an ID of 1).

The attacker then sends a crafted JSON payload via an HTTP POST request to /api/1/authorities using their active authentication session token. The payload explicitly specifies the targeted restricted parent CA ID within the parent object structure.

{
  "name": "attacker-compromised-subca",
  "owner": "attacker@example.com",
  "common_name": "malicious-subca.corp.internal",
  "type": "subca",
  "parent": {
    "id": 1
  },
  "plugin": {
    "slug": "cryptography-issuer"
  },
  "validityStart": "2026-08-18T00:00:00.000Z",
  "validityEnd": "2036-08-18T00:00:00.000Z"
}

On vulnerable versions, Lemur authorizes the global request, fetches the parent CA with ID 1 from the database, and processes the signing operation using the parent's private key. The response returns the cryptographic parameters of the newly minted subordinate CA, exposing its newly generated private key back to the unauthorized attacker. The attacker can then export this private key to sign arbitrary certificates offline, bypassing all internal controls and logging mechanisms.

The security impact of CVE-2026-71317 is high because it compromises the root of trust within the target organization's PKI. An attacker who successfully generates an unauthorized subordinate CA gains the ability to sign valid, fully trusted SSL/TLS leaf certificates for any domain, service, or identity within the corporate namespace.

This can be leveraged to perform highly effective man-in-the-middle (MitM) attacks, decrypt secure network communications, and forge trusted administrative services. Additionally, because the attacker has direct custody of the subordinate CA's private key, they can establish long-term persistence outside the Lemur management framework, signing new leaf certificates indefinitely even if the vulnerability in Lemur is subsequently patched.

The Common Vulnerability Scoring System (CVSS) v3.1 assigns this vulnerability a base score of 6.5. Although the vulnerability resides in an API endpoint, it requires active authenticated access, resulting in a Local (AV:L) attack vector classification. However, the scope change (S:C) and high integrity impact (I:H) emphasize the systemic risk introduced to the broader corporate domain.

The primary recommendation to resolve CVE-2026-71317 is to upgrade the Netflix Lemur installation to version 1.9.3 or higher. This update introduces the necessary parent authority validation check, blocking unauthorized sub-CA generation attempts at the controller layer. System administrators should verify their current deployment version and execute the standard update procedure.

If an immediate upgrade is not feasible, organizations can fully mitigate the threat by modifying the application's configuration. This is achieved by explicitly restricting CA creation to administrators. Administrators must modify the lemur.conf.py file to set ADMIN_ONLY_AUTHORITY_CREATION = True:

# Restrict authority creation to administrators
ADMIN_ONLY_AUTHORITY_CREATION = True

After applying this configuration change, restart the Lemur web services to enforce the restriction. This effectively blocks non-admin users from accessing the vulnerable endpoint logic, rendering the exploit vector unusable by general users. Security teams should also inspect historical Lemur audit logs and certificate inventories for any unexpected subordinate CAs generated by non-admin users prior to the application of the patch.