The Lemur certificate verification process extracts CRL Distribution Point and OCSP responder URLs directly from certificate extensions and issues outbound HTTP requests without restricting the URL scheme or destination. An authenticated user with operator role privileges can craft certificates with malicious URLs pointing to internal or link-local network addresses. This results in SSRF attacks where the Lemur host makes requests to internal services such as EC2 instance metadata endpoints or internal Kubernetes APIs. The vulnerability also allows poisoning of the module-level CRL cache, causing persistent malicious CRL data to be served. The affected endpoint is the POST /api/1/certificates/upload, which triggers verification. The root cause is lack of allow-listing or destination filtering in the network requests made during certificate verification.

An attacker with operator role privileges can perform SSRF attacks from the Lemur host to internal network services, potentially revealing internal network topology and accessing sensitive metadata endpoints (e.g., EC2 IMDS). The attacker can also poison the CRL cache, causing persistent malicious data to affect subsequent certificate verifications. This can impact confidentiality, integrity, and availability of the Lemur host and its network environment. The vulnerability is limited to authenticated operators, reducing the risk compared to unauthenticated SSRF, but still significant given the trust level of operators and the broad processing of third-party certificates.

No official patch or fix is currently confirmed. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Mitigation involves filtering and validating CRL and OCSP URLs before issuing network requests. Recommended approaches include maintaining an explicit allow-list of trusted CRL/OCSP hostnames or using an SSRF-safe HTTP client wrapper that blocks requests to RFC1918, link-local, loopback, and IPv6 ULA addresses and pins resolved IPs to prevent DNS rebinding. Additionally, bounding the CRL cache size can prevent persistent cache poisoning. Operators should restrict certificate uploads to trusted users and monitor for suspicious certificate extensions until a fix is available.