CVE-2026-71303 in Lemur
Summary
by MITRE • 08/18/2026
Lemur manages TLS certificate creation. Prior to 1.9.3, _validate_acme_url enforced ACME_DIRECTORY_HOST_ALLOWLIST when an authority was created, but PUT /api/1/authorities/ passed options to lemur/authorities/service.py without applying the same check. A user holding an authority role could replace the stored acme_url with an internal service or instance-metadata URL such as 169.254.169.254. The next issuance operation loaded that value and passed it to ClientV2.get_directory, causing an outbound request from the Lemur backend. This bypassed the creation-time mitigation for CVE-2026-55166 and could expose internal services or cloud metadata. The fix revalidates acme_url whenever authority options are updated. This issue is fixed in version 1.9.3.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified as CVE-2026-55166 represents a critical authorization bypass within the Lemur certificate management platform, specifically affecting versions prior to 1.9.3. Lemul serves as an automated system for managing TLS certificates, relying heavily on integration with Certificate Authorities via the ACME protocol. The core architectural flaw stems from an inconsistent application of security controls during different phases of authority configuration. While the initial creation process correctly enforced a strict allowlist known as ACME_DIRECTORY_HOST_ALLOWLIST to validate the target ACME directory URL, this validation logic was entirely absent in the update path for existing authorities. This discrepancy created a significant gap where authenticated users with authority-level privileges could manipulate backend configurations without triggering the intended security checks designed to prevent access to untrusted or internal network resources.
From a technical perspective, the flaw resides in the PUT /api/1/authorities/ endpoint which allows modifications to an existing certificate authority's configuration. When this API is invoked, it passes options directly to lemur/authorities/service.py without re-evaluating the acme_url against the ACME_DIRECTORY_HOST_ALLOWLIST. This omission means that a user with appropriate permissions can overwrite the stored acme_url field with arbitrary values. By supplying an internal service address or a cloud instance metadata URL such as 169.254.169.254, which is commonly used by cloud providers to expose sensitive configuration data and credentials to running instances, the attacker effectively redirects the certificate issuance process away from legitimate public Certificate Authorities toward internal infrastructure.
The operational impact of this vulnerability is severe due to its potential for server-side request forgery leading to information disclosure or further network pivoting. When Lemur subsequently attempts to issue a new certificate using the compromised authority configuration, it loads the maliciously set acme_url and passes it to ClientV2.get_directory. This action triggers an outbound HTTP request from the Lemur backend server itself. Because this request originates from within the trusted internal network or cloud environment, it bypasses external perimeter defenses such as firewalls that might otherwise block access to sensitive metadata endpoints or internal services. The attacker can thus leverage the Lemur service account's privileges and network position to probe internal assets, exfiltrate instance metadata containing IAM credentials or SSH keys, or potentially interact with other vulnerable internal APIs exposed via HTTP.
This vulnerability is classified under CWE-284 Improper Access Control because it allows an authenticated user to bypass security restrictions through inconsistent validation logic across different API endpoints. Furthermore, the exploitation technique aligns with MITRE ATT&CK techniques related to Server-Side Request Forgery and Cloud Metadata Endpoint Discovery. The ability to force a backend service to make requests on behalf of an attacker is particularly dangerous in cloud-native environments where metadata services are often unauthenticated or weakly authenticated targets for credential theft.
The resolution implemented in version 1.9.3 addresses this issue by ensuring that the ACME_DIRECTORY_HOST_ALLOWLIST validation is applied consistently whenever authority options are updated, not just during initial creation. This revalidation step guarantees that any attempt to modify the acme_url field undergoes the same rigorous scrutiny as new entries, thereby preventing the injection of internal or malicious URLs. Organizations running Lemur prior to version 1.9.3 should prioritize upgrading immediately to mitigate the risk of unauthorized access to internal resources and potential credential compromise via cloud metadata services. Until an upgrade is performed, administrators should monitor outbound network traffic from Lemur servers for connections to non-standard ACME directories or known instance metadata endpoints as a compensating control.