Netflix Lemur CVE-2026-44305
MEDIUMSeverity by source
AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Lifecycle Timeline
3DescriptionGitHub Advisory
Description
Overview
When LDAP TLS is enabled (LDAP_USE_TLS = True), Lemur's LDAP authentication module unconditionally disables TLS certificate verification at the global ldap module level. This allows a man-in-the-middle attacker positioned between Lemur and the LDAP server to intercept all authentication credentials.
Vulnerable Code
Location: lemur/auth/ldap.py, _bind() method, line ~172
if self.ldap_use_tls:
ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)Key issues:
ldap.set_option()is a global call (as opposed toself.ldap_client.set_option()), meaning it disables TLS verification for the entire Python process, not just this connectionOPT_X_TLS_NEVERmeans no certificate validation is performed whatsoever - self-signed, expired, wrong hostname, and revoked certificates are all silently accepted- There is no configuration option to override this behavior - TLS verification is always disabled when TLS is enabled
Impact
A network-positioned attacker (man-in-the-middle) between Lemur and the LDAP server can:
- Intercept all LDAP credentials (usernames and plaintext passwords) for every user who authenticates
- Modify LDAP responses to inject arbitrary group memberships, granting admin access
- Compromise the entire PKI infrastructure managed by Lemur, since authentication controls access to certificates and private keys
This is particularly severe because Lemur is a certificate management system - the tool designed to manage TLS security is itself vulnerable to a TLS attack.
Steps to Reproduce
- Deploy Lemur with LDAP TLS enabled:
LDAP_AUTH = True
LDAP_USE_TLS = True
LDAP_BIND_URI = "ldaps://dc.corp.example.com"- Intercept the LDAP connection using a TLS proxy (e.g.,
mitmproxyorstunnel):
# Generate a self-signed certificate
openssl req -x509 -newkey rsa:2048 -keyout mitm.key -out mitm.crt -days 1 -nodes -subj "/CN=mitm"
# Proxy LDAP traffic
stunnel -d 0.0.0.0:636 -r real-ldap-server:636 -p mitm.pem- Point Lemur's
LDAP_BIND_URIat the proxy (or perform ARP spoofing/DNS hijacking) - Observe that Lemur connects without any certificate verification error
- All credentials are visible in the proxy's TLS session
Remediation
Remove the global TLS verification bypass and default to strict verification:
if self.ldap_use_tls:
# Use instance-level option, not global
self.ldap_client.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_DEMAND)
self.ldap_client.set_option(ldap.OPT_PROTOCOL_VERSION, 3)
if self.ldap_cacert_file:
self.ldap_client.set_option(ldap.OPT_X_TLS_CACERTFILE, self.ldap_cacert_file)If backward compatibility is needed, make it configurable with a secure default:
tls_require_cert = current_app.config.get("LDAP_TLS_REQUIRE_CERT", ldap.OPT_X_TLS_DEMAND)
self.ldap_client.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, tls_require_cert)Resources
- CWE-295: https://cwe.mitre.org/data/definitions/295.html
- python-ldap TLS documentation: https://www.python-ldap.org/en/python-ldap-3.4.0/reference/ldap.html#tls-options
AnalysisAI
Man-in-the-middle attacks can intercept LDAP credentials in Lemur when LDAP TLS is enabled because the authentication module globally disables TLS certificate verification using ldap.OPT_X_TLS_NEVER. Attackers positioned between Lemur and the LDAP server can capture plaintext usernames and passwords, modify LDAP group responses to grant admin access, and compromise the entire PKI infrastructure managed by Lemur. The vulnerability affects Lemur versions before 1.9.0 and is confirmed fixed in version 1.9.0.
Technical ContextAI
Lemur is a certificate management platform that uses python-ldap for LDAP authentication when LDAP_USE_TLS = True. The vulnerable code in lemur/auth/ldap.py calls the global ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER) method, which disables TLS certificate verification at the Python process level rather than on a per-connection basis. The OPT_X_TLS_NEVER constant means the OpenSSL library accepts all certificates regardless of validity-self-signed, expired, wrong hostname, or revoked certificates are silently accepted. This is a CWE-295 (Improper Certificate Validation) vulnerability in which TLS certificate pinning and hostname verification are completely bypassed, enabling straightforward MITM attacks. The vulnerability exists because there is no configuration option to enable proper certificate validation, and the insecure setting is hardcoded when TLS is enabled.
RemediationAI
Upgrade Lemur to version 1.9.0 or later, which fixes the vulnerability by replacing the global ldap.set_option() call with instance-level options and changing OPT_X_TLS_NEVER to OPT_X_TLS_DEMAND to enforce strict certificate validation. The patched code sets TLS options on the LDAP client instance rather than globally, allowing proper per-connection verification. For organizations unable to upgrade immediately, the following workarounds provide limited mitigation: (1) disable LDAP_USE_TLS and instead configure LDAP_BIND_URI to use ldaps:// protocol with operating system-level TLS verification, though this does not fully remediate the code-level issue; (2) restrict network access to the LDAP server to prevent MITM positioning by implementing network segmentation, firewall rules blocking traffic from unauthorized sources, and monitoring for certificate mismatches; (3) deploy LDAP over a VPN or IPsec tunnel to the directory server, adding a second encryption layer independent of the vulnerable application code. However, these workarounds do not address the root cause and must be considered temporary until upgrade to 1.9.0. Reference the GitHub Security Advisory at https://github.com/advisories/GHSA-vr7c-r5gj-j3w5 for additional context and the release notes at https://github.com/Netflix/lemur/releases/tag/v1.9.0 for upgrade instructions.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
Same weakness CWE-295 – Improper Certificate Validation
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-vr7c-r5gj-j3w5