CVE-2026-71303: Server-Side Request Forgery Bypass in Netflix Lemur Authority Updates

Netflix Lemur functions as a TLS certificate orchestration framework designed to automate certificate generation and deployment. Within Lemur, certificate authorities are created and configured to interact with Automated Certificate Management Environment (ACME) endpoints. The platform relies on configuration directives to control external network operations, defining a strict allowlist of approved ACME directory destinations.

During previous security audits, CVE-2026-55166 was discovered and partially remediated in version 1.9.2. The initial fix implemented a validation routine that checked user-supplied ACME directory URLs against the ACME_DIRECTORY_HOST_ALLOWLIST configuration block. However, this defense-in-depth measure was only integrated into the creation workflow of new authorities, leaving the modification endpoints exposed.

This gap results in a Server-Side Request Forgery (SSRF) vulnerability designated as CVE-2026-71303. An authenticated attacker who holds authority modification privileges can manipulate existing parameters to point to internal services. Consequently, the Lemur backend can be coerced into connecting to restricted network entities, such as the cloud Instance Metadata Service.

The fundamental vulnerability lies in the logical separation between the creation and modification codepaths inside Lemur's authority management engine. When an administrator creates an authority, Lemur invokes the create_authority function. This function references a helper function named _validate_acme_url within the ACME plugin module to parse and verify the target hostname.

In contrast, the authority modification process utilizes a distinct service function inside lemur/authorities/service.py. When an authorized user issues an HTTP PUT request to /api/1/authorities/<id>, the request parameters are routed to the service's update() method. This method accepts the payload parameters, including the options dictionary block, and updates the database records directly.

Prior to version 1.9.3, the update() service method did not apply the validation checks built for the creation workflow. As a result, any modified ACME directory parameters bypass validation check cycles. The values are committed to the application database and subsequently read during normal cryptographic operations, triggering outbound calls to unauthorized destinations.

Analyzing the code diff reveals how the validation functions were reorganized and integrated into the update routine. In the vulnerable implementation, the validation function was defined as a private method within the ACME plugin module.

# Vulnerable private method in lemur/plugins/lemur_acme/plugin.py
-def _validate_acme_url(url):
+def validate_acme_url(url):
     """Reject acme_url values that are not in the configured allowlist.
 
     Called at authority creation time only — existing authorities in the DB

By renaming _validate_acme_url to the public validate_acme_url, the development team made the verification logic accessible to external service components. Within lemur/authorities/service.py, the update function was subsequently refactored to catch unauthorized parameters on update:

# Patched implementation in lemur/authorities/service.py
 def update(authority_id, description, owner, active, roles, options: Optional[str] = None):
     authority.description = description
     authority.owner = owner
     if options:
+        # acme_url can be changed here too, so it must be re-validated against the
+        # allowlist the same way it is at authority creation time (GHSA-v5rc-cpwc-cfpr)
+        from lemur.plugins.lemur_acme.plugin import validate_acme_url
+
+        for option in json.loads(options):
+            if option.get("name") == "acme_url":
+                validate_acme_url(option.get("value", ""))
         authority.options = options

This ensures that whenever the update service method processes an options block, it deserializes the configuration list, searches for any parameter labeled acme_url, and passes its associated value to validate_acme_url. If the value fails the hostname validation, the process throws an exception, and the database transaction is aborted.

To exploit this vulnerability, an attacker must have an active user account associated with a role that is authorized to edit authority configurations. This represents a low-privilege requirement within the application's internal access model. The attack is executed over HTTP through a standard API interaction.

The attacker first identifies an existing ACME authority identifier and targets the update API endpoint: PUT /api/1/authorities/<id>. The payload consists of an options array designed to override the ACME directory URL. This parameter is changed from a standard certificate authority URL to an internal network address.

[
  {
    "name": "acme_url",
    "value": "http://169.254.169.254/latest/meta-data/"
  }
]

Once the database record is updated, the attacker initiates a certificate creation flow that utilizes this authority. The backend schedules the task and attempts to fetch ACME directory resources from the newly configured URL. The Lemur server makes a GET request to the local link-local address, retrieving internal cloud details or API resources and forwarding them through system responses.

The impact of this SSRF is evaluated with a CVSS base score of 7.7. The vulnerability receives a changed scope (S:C) designation because the security posture of resources external to Lemur is altered. Specifically, resources isolated within the internal cloud environment are exposed to requests initiated by the application.

In standard cloud architectures, instances running Lemur may have access to the AWS Instance Metadata Service (IMDS). If IMDSv1 is enabled or if IMDSv2 hop limits are misconfigured, requests targeting 169.254.169.254 can leak temporary security credentials assigned to the host. These credentials can be harvested to gain lateral access to other cloud services.

Additionally, the vulnerability exposes internal microservices, configuration servers, and database APIs that sit behind host perimeter firewalls. Because the outbound connection originates from Lemur's trusted host IP address, internal firewalls will permit the connections, bypassing network boundary protections.

The primary remediation strategy is upgrading to Netflix Lemur version 1.9.3. This version applies correct verification checks to both create and update operations, eliminating the configuration validation bypass. If patching cannot be performed immediately, temporary operational controls should be established.

Administrators should configure host firewalls on the Lemur application servers to deny outbound connections to internal private IP spaces, specifically RFC 1918 subnets and the link-local metadata range. For environments deployed on Amazon Web Services, enforcing IMDSv2 with a maximum hop limit of 1 prevents unauthorized container or runtime interactions from retrieving host credentials.

While the code modifications in 1.9.3 address the direct route bypass, security teams must note that the validation continues to rely on domain-level checks. If the downstream HTTP library handles URL parsing differently from the Python standard library, parser differentials may allow bypasses. DNS rebinding also remains a theoretical vector if hostnames are verified at resolution time but resolved to local IPs during operational execution.