CVE-2026-70666 in Lemur
Summary
by MITRE • 08/18/2026
Lemur manages TLS certificate creation. Prior to 1.9.3, an authority-role member could update acme_url through PUT /api/1/authorities/ without revalidation and direct setup_acme_client_no_retry to an attacker-controlled ACME server. ACME directory and order responses contain newNonce, newOrder, authorizations, and finalize URLs chosen by that server. The Lemur ClientV2 followed those URLs without requiring their host to match the configured directory host, allowing JWS-signed requests to internal services or cloud metadata endpoints. The issue required an ACME authority and a user authorized for that authority, but did not require global administrator privileges. The fix revalidates updates and introduces _PinnedClientNetwork to enforce a single allowed host for the complete ACME flow. This issue is fixed in version 1.9.3.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Lemur prior to version 1.9.3 represents a critical server-side request forgery flaw rooted in improper validation of external service endpoints during TLS certificate provisioning workflows. Lemur serves as an automated management system for Transport Layer Security certificates, relying heavily on the Automated Certificate Management Environment protocol to interact with public or private certification authorities. The core technical deficiency lies within the API endpoint responsible for updating ACME authority configurations via a PUT request at /api/1/authorities/. Specifically, when a user possessing authority-role privileges modifies the acme_url field, the system fails to revalidate the integrity of this configuration change against existing security policies or expected network boundaries. This lack of validation allows an authenticated attacker with limited permissions to redirect the ACME client logic toward a maliciously controlled server rather than the intended legitimate certification authority.
The operational impact of this flaw is severe due to how Lemur processes responses from the ACME protocol. Upon connecting to the specified acme_url, the system receives standard directory and order responses that include critical URLs such as newNonce, newOrder, authorizations, and finalize endpoints. These URLs are entirely determined by the server hosting the ACME service. The vulnerability is exacerbated because Lemur ClientV2 blindly follows these returned URLs without verifying whether their hostnames match the originally configured directory host. This behavior effectively bypasses standard hostname verification checks that would typically prevent redirection to unauthorized destinations. Consequently, an attacker can manipulate this flow to force Lemur to send JSON Web Signature-signed requests to arbitrary internal services or cloud metadata endpoints accessible from the network where Lemur resides.
This misconfiguration enables a sophisticated attack vector known as Server-Side Request Forgery, allowing the compromised system to act as a proxy for authenticated API calls. Since the requests are JWS-signed using credentials stored within the Lemur environment, they carry valid authentication tokens when directed toward internal microservices or cloud provider metadata services such as AWS EC2 instance metadata service or Azure managed identity endpoints. This capability allows an attacker with only authority-role privileges to escalate their access by interacting with backend systems that trust these signed requests, potentially leading to unauthorized data exfiltration, lateral movement within the network, or complete compromise of infrastructure components relying on those internal services. The severity is heightened because global administrator privileges are not required for exploitation, making it accessible to a broader range of potential attackers who may have obtained lower-level credentials through phishing or other initial access techniques.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery and CWE-20 Improper Input Validation within the context of API request handling. It also maps to MITRE ATT&CK technique T1557 Adversary-in-the-Middle, as it facilitates interception or redirection of traffic between Lemur and backend services by manipulating trust relationships in certificate management workflows. The exploitation path involves leveraging valid credentials to modify configuration parameters that directly influence network communication targets, thereby subverting the intended security boundary between external ACME servers and internal infrastructure resources.
The remediation for this issue was implemented in version 1.9.3 through two primary mechanisms. First, the system now performs strict revalidation of updates made to authority configurations, ensuring that changes are checked against established policies before being applied. Second, a new component named _PinnedClientNetwork was introduced to enforce network pinning during the entire ACME flow. This mechanism restricts connections to a single allowed host for all stages of certificate issuance, including nonce retrieval and order finalization. By binding subsequent requests to the originally verified directory host, Lemur prevents attackers from redirecting traffic to malicious endpoints even if they successfully manipulate the initial acme_url configuration. Organizations running versions prior to 1.9.3 should upgrade immediately to mitigate this risk and ensure that certificate management operations remain confined to trusted infrastructure boundaries.