CVE-2026-55162 in Lemur
Summary
by MITRE • 08/18/2026
Lemur manages TLS certificate creation. Prior to 1.9.2, lemur/certificates/verify.py accepted CRL Distribution Point and OCSP responder URLs from uploaded certificate extensions and used them in crl_verify and ocsp_verify without adequate destination validation. An authenticated operator could submit a certificate through POST /api/1/certificates/upload and cause verify_string to reach loopback, RFC1918, link-local, or instance-metadata destinations such as 169.254.169.254. The requests could probe internal services and create side effects from the Lemur host network position. The CRL path also used an unbounded cache, allowing attacker-controlled entries to persist and consume memory. The fix validates destinations, supports explicit trusted-host allowlists, and bounds the CRL cache. This issue is fixed in version 1.9.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Lemur versions prior to 1.9.2 represents a critical server-side request forgery flaw rooted in inadequate input validation within its TLS certificate verification subsystem. Lemur, which automates the management of TLS certificates, processes uploaded X509 certificates through an API endpoint at POST /api/1/certificates/upload. During this process, the system extracts Certificate Revocation List (CRL) Distribution Point URLs and Online Certificate Status Protocol (OCSP) responder URLs embedded within the certificate extensions. The core technical flaw lies in the verify_string function, which utilizes these extracted URLs to perform revocation checks without implementing any form of destination validation or access control restrictions. This oversight allows an authenticated operator to inject arbitrary URLs into the verification process, effectively turning Lemur into a proxy for network reconnaissance and exploitation of internal services that are not directly accessible from external networks.
From an operational perspective, this vulnerability enables significant security risks including unauthorized probing of internal infrastructure and potential denial-of-service conditions due to resource exhaustion. By submitting certificates with maliciously crafted CRL or OCSP URLs pointing towards loopback addresses (127.0.0.1), RFC 1918 private IP ranges, link-local addresses, or cloud instance metadata endpoints such as 169.254.169.254, an attacker can leverage the Lemur host's network position to interact with sensitive internal services. These requests may reveal service versions, trigger unintended side effects on backend systems, or potentially exploit other vulnerabilities present in those internal services that are otherwise protected from external access by firewalls or security groups. The ability to reach instance metadata endpoints is particularly dangerous as it can lead to the exfiltration of temporary credentials and sensitive configuration data stored within cloud environments.
Furthermore, the vulnerability extends beyond network-based attacks into resource management issues due to an unbounded cache associated with CRL verification. When Lemur fetches a Certificate Revocation List, it stores the response in memory without enforcing size limits or expiration policies that adequately account for attacker-controlled inputs. This allows an authenticated user to submit certificates containing large or numerous malicious CRL URLs, causing the system to allocate excessive amounts of memory storing these entries. Over time, this behavior can lead to significant memory consumption and eventual denial-of-service conditions where the Lemur application becomes unresponsive due to resource exhaustion. The persistence of attacker-controlled cache entries exacerbates the impact by ensuring that even after the initial request is processed, the negative effects on system stability continue until manual intervention or service restart occurs.
This issue aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically involving the lack of validation for URLs provided in user-controlled input fields such as certificate extensions. It also relates to CWE-400 Uncontrolled Resource Consumption, where the unbounded caching mechanism allows an attacker to deplete system resources. In terms of offensive security frameworks, this vulnerability facilitates techniques categorized under ATT&CK T1598 Phishing for Information within a Multi-Tenant Environment if used against shared infrastructure, or more broadly under network reconnaissance patterns that leverage trusted internal services to map out the attack surface from within the perimeter. The authenticated nature of the required access means that any user with permission to upload certificates can exploit this flaw, highlighting the importance of strict least-privilege principles in certificate management workflows.
The remediation for this vulnerability involves implementing robust destination validation mechanisms and restricting outbound network connections initiated by the verification process. Version 1.9.2 introduces explicit trusted-host allowlists that define which domains or IP ranges are permitted for CRL and OCSP lookups, effectively blocking requests to internal, loopback, or metadata addresses. Additionally, the fix includes bounds on the CRL cache to prevent uncontrolled memory growth by limiting the number of cached entries and enforcing expiration policies. Organizations running Lemur should immediately upgrade to version 1.9.2 or later to mitigate these risks. In addition to upgrading, administrators should review network segmentation strategies to ensure that even if such a vulnerability were present in other components, the blast radius would be minimized by restricting outbound traffic from application servers to only necessary external endpoints and critical internal services required for legitimate operations.