Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-08-18T19:16:58.217Z",
  "pubdate": "2026-08-18T19:16:58.217Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in Lemur prior to version 1.9.2, specifically within the certificate verification logic.\nThe vulnerability allows an authenticated operator to submit a specially crafted certificate via the POST /api/1/certificates/upload endpoint, forcing the application to issue HTTP or network requests to arbitrary destinations.\nBy manipulating CRL Distribution Point and OCSP responder URLs embedded within uploaded certificate extensions, an attacker can target internal network resources, loopback addresses, RFC1918 private subnets, link-local addresses, and cloud instance metadata services such as 169.254.169.254.\nAdditionally, the vulnerable CRL implementation utilizes an unbounded cache, enabling an attacker to trigger a denial of service (DoS) via memory exhaustion through persistent attacker-controlled entries.\nSuccessful exploitation compromises internal service boundaries and leverages the Lemur host network position to probe restricted infrastructure.\nRemediation requires upgrading to version 1.9.2, which introduces destination validation, trusted-host allowlists, and bounding of the CRL cache.",
  "technicalDetails": "The root cause of the vulnerability stems from inadequate destination validation of CRL Distribution Point and OCSP responder URLs extracted from uploaded certificate extensions within lemur/certificates/verify.py.\nWhen verify_string processes these extensions via crl_verify and ocsp_verify, the application fails to restrict target network destinations against unauthorized scopes.\nExploitation requires authentication as an operator with permission to access the POST /api/1/certificates/upload endpoint.\nAn attacker crafts or modifies a digital certificate containing malicious URIs within the certificate extension fields, pointing to internal network endpoints or cloud metadata services (e.g., 169.254.169.254).\nUpon uploading the certificate, Lemur parses the extensions and automatically initiates outbound requests to the specified URIs without sanitizing or validating the target IP addresses or hostnames.\nThis behavior facilitates Server-Side Request Forgery, permitting the probing of loopback interfaces, RFC1918 address spaces, and link-local destinations from the privileged network position of the Lemur host.\nFurthermore, the processing logic for CRL data leverages an unbounded cache structure, allowing an authenticated adversary to flood the caching layer with malicious or unique entries that persist indefinitely in memory, leading to resource depletion and denial of service.\nThe vulnerable component spans certificate validation routines in lemur/certificates/verify.py affecting Lemur versions prior to 1.9.2."
}