CVE-2026-70667: Server-Side Request Forgery Bypass in Netflix Lemur Certificate Verification

Netflix Lemur orchestrates TLS certificate creation, tracking, and validation within enterprise and cloud environments. Prior to version 1.9.3, the validation component tasked with verifying Certificate Revocation List (CRL) distribution points and Online Certificate Status Protocol (OCSP) endpoints, implemented in lemur/certificates/verify.py, contained fundamental architectural weaknesses.

These weaknesses permitted authenticated operators with certificate-upload privileges to upload custom certificates embedded with malicious, attacker-controlled revocation endpoints. This capability exposed an active internal attack surface, allowing attackers to query resources inside private network spaces (RFC1918) or loopback boundaries.

The vulnerability is classified under CWE-918 (Server-Side Request Forgery) and CWE-367 (Time-of-Check Time-of-Use Race Condition). By abusing these flaws, attackers can establish blind outbound connections to local ports, container management endpoints, or cloud provider metadata endpoints (e.g., AWS IMDS), bypassing previous mitigations established for CVE-2026-55162.

The primary flaw resides in the execution sequence of the URL validation mechanism (_validate_revocation_url) relative to the actual network connections initiated by Lemur.

First, during Certificate Revocation List (CRL) retrieval, the system executed the standard Python requests.get(url) function on the extracted CRL URL. Because the default configuration of the requests library follows HTTP redirects (such as 301, 302, 303, 307, and 308 responses) automatically, an attacker-controlled external domain could pass the initial IP validation phase and then redirect the client connection to an internal address like 169.254.169.254 or 127.0.0.1.

Second, the validation workflow was vulnerable to a DNS Rebinding Time-of-Check Time-of-Use (TOCTOU) race condition. The validation logic initially resolved the target domain to verify that the target IP was not within a restricted, loopback, or link-local subnet range. However, immediately after passing this check, the application initiated a separate, independent network request via requests.get (for CRLs) or via the external openssl ocsp utility (for OCSP verification). This second request triggered a second DNS lookup.

By configuring an authoritative DNS server with a Time-to-Live (TTL) of 0 seconds, an attacker could program the server to return a safe, public IP during the validation phase (Time-of-Check) and then return a private, internal IP during the connection phase (Time-of-Use). This completely bypassed the host validation filter.

An analysis of the fix in commit ed504a830f38a83825b1570302e9f38d6553938a shows how the developer closed both bypass vectors by modifying lemur/certificates/verify.py.

In the patched version, _validate_revocation_url is updated to return the resolved IP address (str(addr)) after performing safety checks. This allows the calling functions to 'pin' the hostname to a specific, validated IP address.

To prevent DNS rebinding, the helper function _pin_url_to_ip(url, resolved_ip) replaces the hostname in the HTTP URL with the validated IP address. Because this replacement breaks HTTPS Server Name Indication (SNI) and TLS host verification, it is strictly restricted to http schemes. To ensure the remote server can route virtual hosts correctly, the original host header is preserved and explicitly passed as an HTTP header.

# Patched implementation in lemur/certificates/verify.py
def _pin_url_to_ip(url, resolved_ip):
    parsed = urlparse(url)
    if parsed.scheme != "http":
        return url
    port = parsed.port
    netloc = f"{resolved_ip}:{port}" if port else resolved_ip
    return parsed._replace(netloc=netloc).geturl()

Additionally, the HTTP redirect vector is mitigated in crl_verify by explicitly setting allow_redirects=False in the requests.get call:

# Patched request invocation in crl_verify
response = requests.get(
    pinned_url,
    timeout=(3.05, 6),
    allow_redirects=False,
    headers={"Host": _host_header(point)},
)

This modification prevents the client from following Location headers, neutralising the redirect bypass. However, the limitation of this patch is that HTTPS endpoints are not pinned to prevent rebinding, meaning a theoretical risk remains if an attacker can manipulate TLS bindings on internal endpoints.

An attacker seeking to exploit CVE-2026-70667 must possess certificate upload privileges on the target Lemur instance. The exploitation can proceed via two primary vectors depending on the targeted revocation path.

Scenario A: HTTP Redirect Bypass (CRL Path)

1. The attacker sets up an external web server that responds to incoming requests with a 302 Found redirect pointing to http://169.254.169.254/latest/meta-data/.
2. The attacker generates an X.509 certificate containing a CRL Distribution Point extension pointing to the external server: URI: http://attacker-server.com/crl.crl.
3. The attacker uploads this certificate via the POST /api/1/certificates/upload endpoint.
4. Lemur parses the certificate, validates that attacker-server.com resolves to a public IP, and then makes a request to it. The server follows the redirect directly to the AWS IMDS endpoint, returning metadata to the log files or application responses.

Scenario B: DNS Rebinding Bypass (OCSP/CRL Path)

1. The attacker configures a malicious DNS server for the domain rebind.attacker.com with a TTL of 0.
2. The DNS server is programmed to resolve the first query to 1.1.1.1 (public) and the second query to 127.0.0.1 (internal loopback).
3. The attacker uploads a certificate with an Authority Information Access (AIA) extension containing the OCSP URI: http://rebind.attacker.com/ocsp.
4. Lemur's validation logic queries DNS, receives 1.1.1.1, and validates the URL. Then, the execution tool (openssl ocsp) queries DNS a second time, receives 127.0.0.1, and establishes a TCP handshake with the local interface on the Lemur host.

The concrete impact of this vulnerability is a complete bypass of SSRF protections on the host server. An attacker can map internal ports, communicate with backend VPC databases, or query orchestrators. In AWS environments, this exposure can lead to the retrieval of IAM credentials, configuration parameters, and access keys from the Instance Metadata Service (IMDSv1).

To address this vulnerability, administrators must upgrade Netflix Lemur instances to version 1.9.3 or later. This version implements resolution pinning and disables HTTP redirects on CRL validation paths.

If immediate updates are not feasible, the following workarounds should be applied:

1. Restrict administrative access to the POST /api/1/certificates/upload endpoint using role-based access controls.
2. Implement outbound firewall rules (egress filtering) at the host or VPC network level to prevent the Lemur application process from communicating with private subnets, including the link-local metadata address 169.254.169.254/32.
3. Ensure AWS IMDSv2 is enforced with a hop limit of 1 to prevent metadata harvesting from containerized environments or reverse-proxy setups.