Listen to this Post
The SSRF mitigation added for GHSA-54vg-pfh7-jq95 (_validate_revocation_url() in lemur/certificates/verify.py) can be bypassed. An operator-role user who uploads a certificate with attacker-controlled CRL/OCSP extensions can still make Lemur reach internal destinations (RFC1918, loopback, link-local 169.254.169.254) during verification.
The initial guard `_validate_revocation_url()` was introduced to prevent SSRF by validating the URL extracted from the certificate’s CRL Distribution Point or OCSP extension. However, this validation is incomplete. In lemur/certificates/verify.py, the CRL fetch uses requests.get(point, timeout=(3.05, 6)). The guard validates only the initial URL in the certificate, but the `requests.get` call follows HTTP redirects without re-validating the target. An attacker can host the CRL URL on a public host they control (which passes the guard) and have that host return a 302 Location: http://169.254.169.254/....` redirect. The `requests` library follows it to the internal target the guard never inspected.addr = ipaddress.ip_address(socket.gethostbyname(hostname))
Additionally, the guard resolves the hostname once during validation (), while the fetch re-resolves independently. An attacker can use a low-TTL domain that answers with a public IP during the guard's check but resolves to an internal IP (e.g., 169.254.169.254) at fetch time, bypassing the protection. This same gap affects the OCSP path, where the URL is passed toopenssl ocsp -url . This is an incomplete fix for GHSA-54vg-pfh7-jq95; the bypass via redirects is not mentioned in the original advisory.ocsp_verify
The affected endpoint is `POST /api/1/certificates/upload` (operator role) → `verify_string` → `crl_verify` /. This is triggered when verification runs (e.g., the `check_revocation` task).302 Location: http://169.254.169.254/….` and `requests` follows it to the internal target the guard never inspected.
<h2 style="color: blue;">DailyCVE Form:</h2>
Platform: Lemur
Version: < 1.9.3
Vulnerability: SSRF Bypass
Severity: Medium (CVSS 6.3)
date: 2026-08-18
<h2 style="color: blue;">Prediction: 2026-08-18 (Patched in 1.9.3)</h2>
<h2 style="color: blue;">What Undercode Say:</h2>
The vulnerability stems from two distinct flaws in the SSRF mitigation.
<h2 style="color: blue;">Bypass 1 – HTTP Redirect (Deterministic)</h2>
The guard validates only the URL in the certificate; the CRL fetch then follows redirects without re-validating the target. The attacker hosts the CRL URL on a public host they control (passes the guard); that host returns
Bypass 2 – DNS Rebinding / TOCTOU (Probabilistic)
The guard resolves once during validation; the fetch re-resolves independently. A low-TTL attacker name that answers a public IP at check time and an internal IP at fetch time passes the guard but is fetched internally. Same gap affects the OCSP path (openssl ocsp -url <url>).
Affected Code Snippets
lemur/certificates/verify.py - CRL fetch follows redirects response = requests.get(point, timeout=(3.05, 6)) Bypass 1 lemur/certificates/verify.py - Guard resolves once addr = ipaddress.ip_address(socket.gethostbyname(hostname)) Bypass 2 lemur/certificates/verify.py - OCSP path p2 = subprocess.Popen(["openssl", "ocsp", "-issuer", issuer_chain_path, "-cert", cert_path, "-url", url.strip()]) Bypass 2
Exploit: (Educational Purposes!)
Prerequisites:
- Operator role access to Lemur
- Ability to upload a certificate via `POST /api/1/certificates/upload`
PoC Steps:
- Generate a malicious certificate with `crlDistributionPoints = URI:http://attacker.example/crl`.
2. For Bypass 1 (HTTP Redirect):
– On attacker.example, host a CRL endpoint that returns:
HTTP/1.1 302 Found Location: http://169.254.169.254/latest/meta-data/
3. For Bypass 2 (DNS Rebinding):
– Register a domain `rebind.example` with a very low TTL (e.g., 1 second).
– Configure the DNS to resolve to a public IP (e.g., 1.2.3.4) most of the time, but switch to `169.254.169.254` during the fetch window.
4. Upload the certificate via `POST /api/1/certificates/upload` as an operator user.
5. Trigger certificate verification (e.g., run the `lemur certificate check_revocation` task).
6. Observe the request reaching the internal address:
tcpdump -nni any host 169.254.169.254
Protection:
– Update Lemur to version 1.9.3 or later, which contains the official fix.
– The fix disables HTTP redirects on CRL fetches (allow_redirects=False).
– The fix resolves the hostname once, pins the validated IP address, and reuses it for the connection, defeating DNS rebinding.
– As a workaround, implement an SSRF-safe HTTP client that validates every redirect hop and rejects internal addresses.
Impact:
- Blind SSRF from the Lemur host, allowing an attacker to reach internal services and instance metadata (e.g., `169.254.169.254` without IMDSv2 enforcement).
- On EC2 instances, this can expose sensitive instance metadata.
- The response is parsed as a CRL and discarded, making it a blind SSRF — impact is limited to reachability and side-effects, not direct response exfiltration.
- The operator-role precondition reduces severity, but operators are still less trusted than the host’s network position, and PKI workflows routinely process third-party certificates.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
