Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| lemur | pip | < 1.9.3 | 1.9.3 |
Miggo AIRoot Cause AnalysisThe vulnerability is an incomplete fix for a previous SSRF vulnerability (GHSA-54vg-pfh7-jq95). The patch for the original vulnerability introduced a validation function, _validate_revocation_url, but the functions performing the network requests, crl_verify and ocsp_verify, did not use the validated information correctly, leaving them open to bypasses.
crl_verify: This function was vulnerable to two bypass techniques:
requests.get() to fetch the CRL URL. By default, requests follows HTTP redirects. An attacker could provide a certificate with a CRL URL pointing to a server they control, which would pass the initial validation. This server could then issue a redirect (e.g., 302 Location) to an internal IP address, causing Lemur to make a request to an internal service. The patch mitigates this by setting allow_redirects=False in the requests.get() call.ocsp_verify: This function was vulnerable to the same DNS rebinding (TOCTOU) attack. It would validate the OCSP URL but then pass the original URL to the openssl ocsp command-line tool. The openssl tool would perform its own DNS lookup, which could be manipulated by an attacker to point to an internal IP. The patch addresses this by passing the pinned, pre-validated IP to the openssl command.
The vulnerable functions are the ones that execute the network requests (crl_verify and ocsp_verify) because they contained the flawed logic that could be bypassed.