PYSEC-2026-3676

See a problem?
Import Source
https://github.com/pypa/advisory-database/blob/main/vulns/lemur/PYSEC-2026-3676.yaml
JSON Data
https://api.osv.dev/v1/vulns/PYSEC-2026-3676
Aliases
Published
2026-08-19T11:56:28Z
Modified
2026-08-19T12:45:08Z
Severity
  • 6.3 (Medium) CVSS_V3 - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L CVSS Calculator
Summary
Lemur: SSRF protection in certificate revocation checking bypassable via HTTP redirects and DNS rebinding (incomplete fix for GHSA-54vg-pfh7-jq95)
Details

Summary

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.

Affected version

Tested against main (the commit that introduced _validate_revocation_url). The 1.9.2 release predates that guard and is vulnerable to the original SSRF (GHSA-54vg-pfh7-jq95) directly; this bypass applies to the unreleased mitigation in main. Please map the affected range to whichever release will first contain _validate_revocation_url.

Bypass 1 — HTTP redirect (deterministic)

The guard validates only the URL in the certificate; the CRL fetch then follows redirects without re-validating the target:

# lemur/certificates/verify.py:174
response = requests.get(point, timeout=(3.05, 6))   

The attacker hosts the CRL URL on a public host they control (passes the guard); that host returns 302 Location: http://169.254.169.254/.... requests follows it to the internal target the guard never inspected.

Bypass 2 — DNS rebinding / TOCTOU (probabilistic)

The guard resolves once during validation; the fetch re-resolves independently:

# lemur/certificates/verify.py:51
addr = ipaddress.ip_address(socket.gethostbyname(hostname))

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>, verify.py:90-99).

Relationship to GHSA-54vg-pfh7-jq95

Incomplete-fix of that mitigation, not a duplicate. Bypass 1 is not mentioned there; bypass 2 is the rebinding gap that advisory's remediation text anticipated ("pins the resolved IP") but the code does not implement.

Affected endpoint

POST /api/1/certificates/upload (operator role) → verify_string → crl_verify / ocsp_verify. Triggered when verification runs (e.g. the check_revocation task).

PoC

  1. Generate a cert with crlDistributionPoints = URI:http://attacker.example/crl.
  2. That host returns 302 Location: http://169.254.169.254/latest/meta-data/... (bypass 1), or use a low-TTL rebinding name (bypass 2).
  3. Upload via POST /api/1/certificates/upload as an operator user.
  4. Trigger lemur certificate check_revocation.
  5. Observe the request reach the internal address (tcpdump -nni any host 169.254.169.254).
poc-1

Impact

Blind SSRF from the Lemur host: reach internal services and instance metadata (169.254.169.254 without IMDSv2). Response is parsed as a CRL and discarded — reachability/side-effects, not response exfiltration.

Remediation

  • allow_redirects=False on CRL fetches (or re-validate every redirect hop).
  • Resolve once, pin the IP, connect to the pinned address; route the OCSP URL through the same check.
  • Reject names with any internal A/AAAA record.
References

Affected packages

PyPI / lemur

Package

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected
Fixed
1.9.3

Affected versions

0.*
0.2.1
0.8.0
0.8.1
0.9.0
0.11.0
1.*
1.0.0
1.1.0
1.2.0
1.3.1
1.3.2
1.4.0
1.5.0
1.6.0
1.7.0
1.8.0
1.8.1
1.8.2
1.9.0
1.9.1
1.9.2

Database specific

source
"https://github.com/pypa/advisory-database/blob/main/vulns/lemur/PYSEC-2026-3676.yaml"