CVE-2026-70667: Lemur: SSRF protection in certificate revocation checking bypassable via HTTP redirects and DNS rebinding (incomplete fix for CVE-2026-55162)
Lemur manages TLS certificate creation. Prior to 1.9.3, validaterevocationurl 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
lemurto a version that resolves this vulnerability.Fixed in 1.9.3 - Configuration
In _validate_revocation_url, disable following HTTP redirects during CRL fetching so Location targets are not allowed to change the destination (fixed in 1.9.3).
lemur/certificates/verify.py (CRL/OCSP revocation checking) HTTP redirects handling for CRL requests.get = disabled - Configuration
In _validate_revocation_url, pin the validated CRL/OCSP destination addresses and preserve the correct Host value so the request cannot be redirected to loopback/RFC1918/link-local/instance-metadata targets (fixed in 1.9.3).
lemur/certificates/verify.py (CRL/OCSP revocation checking) Destination address validation / pinning = pin validated addresses and preserve Host - Configuration
In _validate_revocation_url, remove the TOCTOU window by avoiding separate DNS resolutions for validation vs connection on both the CRL and OCSP paths (fixed in 1.9.3).
lemur/certificates/verify.py (CRL/OCSP revocation checking) DNS resolution handling to prevent TOCTOU = single-resolution / avoid separate DNS resolution
Event History
Frequently Asked Questions
Who can realistically trigger the issue?
Instances running Lemur before 1.9.3 are affected when an operator can upload a certificate through POST /api/1/certificates/upload. Exploitation requires only low-privileged access and no user interaction.
What does an attacker need to exploit this?
An attacker can supply certificate revocation URLs that begin at an attacker-controlled public endpoint, then redirect to internal destinations or exploit DNS rebinding between validation and connection. The resulting requests are blind internal requests on both CRL and OCSP validation paths.
What is the recommended remediation?
Upgrade Lemur to version 1.9.3. The fix disables redirects during revocation checking and pins the validated address while preserving the intended Host value.