CVE-2026-70667 in Lemur
Summary
by MITRE • 08/18/2026
Lemur manages TLS certificate creation. Prior to 1.9.3, _validate_revocation_url in lemur/certificates/verify.py checked the original CRL or OCSP URL but the later request could reach a different destination. The CRL requests.get call followed HTTP redirects without validating each Location target, so a public attacker-controlled URL could redirect to loopback, RFC1918, link-local, or instance-metadata addresses. Validation and connection also performed separate DNS resolutions, creating a time-of-check time-of-use window for DNS rebinding on both CRL and OCSP paths. An operator uploading a certificate through POST /api/1/certificates/upload could therefore induce blind internal requests despite the earlier mitigation. The fix disables redirects and pins validated addresses while preserving the correct Host value. This issue is fixed in version 1.9.3.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Lemur, a platform for managing TLS certificate lifecycles, stems from improper validation of Uniform Resource Locators during the revocation checking process. Specifically, the _validate_revocation_url function within lemur/certificates/verify.py failed to enforce strict destination controls when fetching Certificate Revocation Lists or Online Certificate Status Protocol responses. While the initial check might have validated a specific URL provided by an attacker uploading a certificate via the POST /api/1/certificates/upload endpoint, the subsequent HTTP request executed using requests.get did not restrict redirects. This architectural flaw allowed the application to follow Location headers from external servers without re-validating the final destination against security policies. Consequently, an authenticated operator could supply a maliciously crafted URL that initially appears benign but redirects traffic toward internal network addresses such as loopback interfaces, RFC1918 private address spaces, link-local addresses, or cloud instance metadata endpoints. This behavior effectively creates a blind server-side request forgery scenario where the application acts on behalf of an attacker to probe or interact with internal infrastructure services that are otherwise inaccessible from the public internet.
The technical root cause involves two distinct failure modes within the network communication layer. First, the HTTP client library was configured to follow redirects by default without implementing a custom redirect handler that validates each intermediate and final Location header against an allowlist of trusted domains or IP ranges. This lack of destination validation means that even if the initial URL is verified as safe, any subsequent hop in the chain can divert traffic to arbitrary internal resources. Second, the implementation suffered from a time-of-check to time-of-use race condition related to DNS resolution. The system performed separate DNS lookups during the initial validation phase and again when establishing the actual connection. This temporal gap allows for DNS rebinding attacks where an attacker controls a domain that resolves to a safe external IP address initially but changes its record to point to an internal private IP by the time the second request is made. These combined flaws enable attackers to bypass network segmentation boundaries, potentially accessing sensitive metadata services like AWS EC2 instance metadata or internal API endpoints, leading to unauthorized data exfiltration or further lateral movement within the organization's infrastructure.
From a classification perspective, this vulnerability aligns with CWE-918 Server Side Request Forgery and CWE-400 Uncontrolled Resource Consumption if used in denial-of-service scenarios, though SSRF is the primary concern here. In terms of offensive security frameworks, it maps to MITRE ATT&CK technique T1557 Adversary-in-the-Middle or more specifically T1098 Account Manipulation if leveraged for credential theft via metadata access, but most accurately reflects T1642 Payload Injection which involves manipulating inputs to cause the system to make unintended network requests. The operational impact is severe because it allows an attacker with permission to upload certificates, a common role in DevOps or security operations teams, to perform reconnaissance against internal networks. By inducing these blind internal requests, attackers can fingerprint services running on private IPs, attempt to exploit known vulnerabilities in those services, or extract sensitive configuration data from cloud provider metadata endpoints that often contain temporary credentials and instance details.
The remediation strategy implemented in version 1.9.3 addresses both the redirect handling and DNS resolution issues comprehensively. The fix disables automatic HTTP redirects entirely for revocation checks, ensuring that only the initially validated URL is contacted without any possibility of redirection to alternative destinations. Additionally, the code now pins the resolved IP address after validation, preventing DNS rebinding attacks by using the specific IP obtained during the initial check rather than performing a new lookup at connection time. The implementation also preserves the correct Host header value to maintain protocol compliance while ensuring that the underlying network destination remains strictly controlled and validated against security policies. Organizations running versions prior to 1.9.3 should upgrade immediately to mitigate this risk. In addition to upgrading, operators should review their certificate upload workflows to ensure least-privilege access controls are in place, limiting who can submit certificates for validation. Network-level mitigations such as egress filtering and web application firewalls that inspect outbound traffic from the Lemur server can also provide defense-in-depth against similar SSRF attempts targeting internal resources.