CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
2039 vulnerabilities reference this CWE, most recent first.
GHSA-VJXV-H84W-VJ5J
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34An issue exists in PrimeKey EJBCA before 7.4.3 when enrolling with EST while proxied through an RA over the Peers protocol. As a part of EJBCA's domain security model, the peer connector allows the restriction of client certificates (for the RA, not the end user) to a limited set of allowed CAs, thus restricting the accessibility of that RA to the rights it has within a specific role. While this works for other protocols such as CMP, it was found that the EJBCA enrollment over an EST implementation bypasses this check, allowing enrollment with a valid client certificate through any functioning and authenticated RA connected to the CA. NOTE: an attacker must already have a trusted client certificate and authorization to enroll against the targeted CA.
{
"affected": [],
"aliases": [
"CVE-2020-28942"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-19T17:15:00Z",
"severity": "MODERATE"
},
"details": "An issue exists in PrimeKey EJBCA before 7.4.3 when enrolling with EST while proxied through an RA over the Peers protocol. As a part of EJBCA\u0027s domain security model, the peer connector allows the restriction of client certificates (for the RA, not the end user) to a limited set of allowed CAs, thus restricting the accessibility of that RA to the rights it has within a specific role. While this works for other protocols such as CMP, it was found that the EJBCA enrollment over an EST implementation bypasses this check, allowing enrollment with a valid client certificate through any functioning and authenticated RA connected to the CA. NOTE: an attacker must already have a trusted client certificate and authorization to enroll against the targeted CA.",
"id": "GHSA-vjxv-h84w-vj5j",
"modified": "2022-05-24T17:34:39Z",
"published": "2022-05-24T17:34:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28942"
},
{
"type": "WEB",
"url": "https://support.primekey.com/news/posts/40"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-VM4W-44CM-HC57
Vulnerability from github – Published: 2025-06-15 15:30 – Updated: 2025-06-15 15:30IBM MQ Operator LTS 2.0.0 through 2.0.29, MQ Operator CD 3.0.0, 3.0.1, 3.1.0 through 3.1.3, 3.3.0, 3.4.0, 3.4.1, 3.5.0, 3.5.1 through 3.5.3, and MQ Operator SC2 3.2.0 through 3.2.12 Native HA CRR could be configured with a private key and chain other than the intended key which could disclose sensitive information or allow the attacker to perform unauthorized actions.
{
"affected": [],
"aliases": [
"CVE-2025-36041"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-15T13:15:33Z",
"severity": "MODERATE"
},
"details": "IBM MQ Operator LTS 2.0.0 through 2.0.29, MQ Operator CD 3.0.0, 3.0.1, 3.1.0 through 3.1.3, 3.3.0, 3.4.0, 3.4.1, 3.5.0, 3.5.1 through 3.5.3, and MQ Operator SC2 3.2.0 through 3.2.12 Native HA CRR could be configured with a private key and chain other than the intended key which could disclose sensitive information or allow the attacker to perform unauthorized actions.",
"id": "GHSA-vm4w-44cm-hc57",
"modified": "2025-06-15T15:30:30Z",
"published": "2025-06-15T15:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36041"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7236608"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VMH5-MC38-953G
Vulnerability from github – Published: 2026-06-18 14:28 – Updated: 2026-06-18 14:28Impact
undici's ProxyAgent silently drops the requestTls option when configured with a SOCKS5 proxy URI (socks5:// or socks://). The target HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store, ignoring user-configured ca, cert, key, rejectUnauthorized, and servername settings.
Applications that pin to an internal or corporate CA via requestTls.ca will, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange.
Affected applications are those that use undici's ProxyAgent (or Socks5ProxyAgent directly) with SOCKS5 AND rely on requestTls for TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added.
Patches
Upgrade to undici v7.28.0 or v8.5.0.
Workarounds
No workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy ProxyAgent instead, where requestTls is honored correctly.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "7.23.0"
},
{
"fixed": "7.28.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-9697"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T14:28:21Z",
"nvd_published_at": "2026-06-17T18:18:06Z",
"severity": "HIGH"
},
"details": "## Impact\n\nundici\u0027s `ProxyAgent` silently drops the `requestTls` option when configured with a SOCKS5 proxy URI (`socks5://` or `socks://`). The target HTTPS connection through the SOCKS5 tunnel falls back to Node\u0027s default trust store, ignoring user-configured `ca`, `cert`, `key`, `rejectUnauthorized`, and `servername` settings.\n\nApplications that pin to an internal or corporate CA via `requestTls.ca` will, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange.\n\nAffected applications are those that use undici\u0027s `ProxyAgent` (or `Socks5ProxyAgent` directly) with SOCKS5 AND rely on `requestTls` for TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added.\n\n## Patches\n\nUpgrade to undici v7.28.0 or v8.5.0.\n\n## Workarounds\n\nNo workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy `ProxyAgent` instead, where `requestTls` is honored correctly.",
"id": "GHSA-vmh5-mc38-953g",
"modified": "2026-06-18T14:28:21Z",
"published": "2026-06-18T14:28:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-vmh5-mc38-953g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9697"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodejs/undici"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "undici vulnerable to TLS certificate validation bypass via dropped requestTls in SOCKS5 ProxyAgent"
}
GHSA-VP9F-WMXX-376H
Vulnerability from github – Published: 2022-05-17 02:45 – Updated: 2025-04-20 03:37The State Bank of India State Bank Anywhere app 5.1.0 for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.
{
"affected": [],
"aliases": [
"CVE-2017-5901"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-05-05T07:29:00Z",
"severity": "MODERATE"
},
"details": "The State Bank of India State Bank Anywhere app 5.1.0 for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.",
"id": "GHSA-vp9f-wmxx-376h",
"modified": "2025-04-20T03:37:14Z",
"published": "2022-05-17T02:45:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5901"
},
{
"type": "WEB",
"url": "https://medium.com/%40chronic_9612/follow-up-76-popular-apps-confirmed-vulnerable-to-silent-interception-of-tls-protected-data-64185035029f"
},
{
"type": "WEB",
"url": "https://medium.com/@chronic_9612/follow-up-76-popular-apps-confirmed-vulnerable-to-silent-interception-of-tls-protected-data-64185035029f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VQ58-8WP2-WC83
Vulnerability from github – Published: 2025-05-07 18:30 – Updated: 2025-05-07 18:30A vulnerability in certificate validation processing of Cisco Catalyst SD-WAN Manager, formerly Cisco SD-WAN vManage, could allow an unauthenticated, remote attacker to gain access to sensitive information.
This vulnerability is due to improper validation of certificates that are used by the Smart Licensing feature. An attacker with a privileged network position could exploit this vulnerability by intercepting traffic that is sent over the Internet. A successful exploit could allow the attacker to gain access to sensitive information, including credentials used by the device to connect to Cisco cloud services.
{
"affected": [],
"aliases": [
"CVE-2025-20157"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-07T18:15:37Z",
"severity": "MODERATE"
},
"details": "A vulnerability in certificate validation processing of Cisco Catalyst SD-WAN Manager, formerly Cisco SD-WAN vManage, could allow an unauthenticated, remote attacker to gain access to sensitive information.\n\nThis vulnerability is due to improper validation of certificates that are used by the Smart Licensing feature. An attacker with a privileged network position could exploit this vulnerability by intercepting traffic that is sent over the Internet. A successful exploit could allow the attacker to gain access to sensitive information, including credentials used by the device to connect to Cisco cloud services.",
"id": "GHSA-vq58-8wp2-wc83",
"modified": "2025-05-07T18:30:48Z",
"published": "2025-05-07T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20157"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-catalyst-tls-PqnD5KEJ"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VQ7P-F4FV-RR5X
Vulnerability from github – Published: 2022-05-14 03:23 – Updated: 2022-12-12 21:29A man in the middle vulnerability exists in Jenkins vSphere Plugin 2.16 and older in VSphere.java that disables SSL/TLS certificate validation by default. vSphere Plugin 2.17 now has SSL/TLS certificate validation enabled by default.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.16"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:vsphere-cloud"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000151"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-12T21:29:46Z",
"nvd_published_at": "2018-04-05T13:29:00Z",
"severity": "MODERATE"
},
"details": "A man in the middle vulnerability exists in Jenkins vSphere Plugin 2.16 and older in VSphere.java that disables SSL/TLS certificate validation by default. vSphere Plugin 2.17 now has SSL/TLS certificate validation enabled by default.",
"id": "GHSA-vq7p-f4fv-rr5x",
"modified": "2022-12-12T21:29:46Z",
"published": "2022-05-14T03:23:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000151"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/vsphere-cloud-plugin/commit/f0fb143af340c7529dd9e50f5514334756019356"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/vsphere-cloud-plugin"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2018-03-26/#SECURITY-504"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Jenkins vSphere Plugin disables SSL/TLS certificate validation by default"
}
GHSA-VQHR-M87Q-9JQH
Vulnerability from github – Published: 2026-01-08 12:30 – Updated: 2026-01-08 15:31When doing TLS related transfers with reused easy or multi handles and
altering the CURLSSLOPT_NO_PARTIALCHAIN option, libcurl could accidentally
reuse a CA store cached in memory for which the partial chain option was
reversed. Contrary to the user's wishes and expectations. This could make
libcurl find and accept a trust chain that it otherwise would not.
{
"affected": [],
"aliases": [
"CVE-2025-14819"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-08T10:15:46Z",
"severity": "MODERATE"
},
"details": "When doing TLS related transfers with reused easy or multi handles and\naltering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally\nreuse a CA store cached in memory for which the partial chain option was\nreversed. Contrary to the user\u0027s wishes and expectations. This could make\nlibcurl find and accept a trust chain that it otherwise would not.",
"id": "GHSA-vqhr-m87q-9jqh",
"modified": "2026-01-08T15:31:25Z",
"published": "2026-01-08T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14819"
},
{
"type": "WEB",
"url": "https://curl.se/docs/CVE-2025-14819.html"
},
{
"type": "WEB",
"url": "https://curl.se/docs/CVE-2025-14819.json"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/01/07/5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VQJM-CH4V-X2F4
Vulnerability from github – Published: 2024-09-18 21:30 – Updated: 2024-09-18 21:30Anbox Management Service, in versions 1.17.0 through 1.23.0, does not validate the TLS certificate provided to it by the Anbox Stream Agent. An attacker must be able to machine-in-the-middle the Anbox Stream Agent from within an internal network before they can attempt to take advantage of this.
{
"affected": [],
"aliases": [
"CVE-2024-8287"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-18T19:15:41Z",
"severity": "HIGH"
},
"details": "Anbox Management Service, in versions 1.17.0 through 1.23.0, does not validate the TLS certificate provided to it by the Anbox Stream Agent. An attacker must be able to machine-in-the-middle the Anbox Stream Agent from within an internal network before they can attempt to take advantage of this.",
"id": "GHSA-vqjm-ch4v-x2f4",
"modified": "2024-09-18T21:30:48Z",
"published": "2024-09-18T21:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8287"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/anbox-cloud/+bug/2077570"
},
{
"type": "WEB",
"url": "https://discourse.ubuntu.com/t/anbox-cloud-1-23-1-has-been-released/48141"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8287"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-VQVM-4FM4-4H2W
Vulnerability from github – Published: 2024-05-31 18:31 – Updated: 2025-11-04 00:30IBM Security Verify Access Docker 10.0.0 through 10.0.6 could allow a local user to escalate their privileges due to improper certificate validation. IBM X-Force ID: 292416.
{
"affected": [],
"aliases": [
"CVE-2024-35140"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-31T17:15:08Z",
"severity": "HIGH"
},
"details": "IBM Security Verify Access Docker 10.0.0 through 10.0.6 could allow a local user to escalate their privileges due to improper certificate validation. IBM X-Force ID: 292416.",
"id": "GHSA-vqvm-4fm4-4h2w",
"modified": "2025-11-04T00:30:49Z",
"published": "2024-05-31T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35140"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/292416"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7155356"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Nov/0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VR7C-R5GJ-J3W5
Vulnerability from github – Published: 2026-05-06 18:48 – Updated: 2026-05-13 16:41Description
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:
python 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): ```bash # 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
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "lemur"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44305"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T18:48:12Z",
"nvd_published_at": "2026-05-12T22:16:37Z",
"severity": "MODERATE"
},
"details": "## Description\n\n### Overview\n\nWhen LDAP TLS is enabled (`LDAP_USE_TLS = True`), Lemur\u0027s 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.\n\n### Vulnerable Code\n\n**Location:** `lemur/auth/ldap.py`, `_bind()` method, line ~172\n\n```python\nif self.ldap_use_tls:\n ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)\n```\n\nKey issues:\n\n1. `ldap.set_option()` is a **global** call (as opposed to `self.ldap_client.set_option()`), meaning it disables TLS verification for the entire Python process, not just this connection\n2. `OPT_X_TLS_NEVER` means no certificate validation is performed whatsoever \u2014 self-signed, expired, wrong hostname, and revoked certificates are all silently accepted\n3. There is no configuration option to override this behavior \u2014 TLS verification is always disabled when TLS is enabled\n\n### Impact\n\nA network-positioned attacker (man-in-the-middle) between Lemur and the LDAP server can:\n\n- **Intercept all LDAP credentials** (usernames and plaintext passwords) for every user who authenticates\n- **Modify LDAP responses** to inject arbitrary group memberships, granting admin access\n- **Compromise the entire PKI infrastructure** managed by Lemur, since authentication controls access to certificates and private keys\n\nThis is particularly severe because Lemur is a certificate management system \u2014 the tool designed to manage TLS security is itself vulnerable to a TLS attack.\n\n### Steps to Reproduce\n\n1. Deploy Lemur with LDAP TLS enabled:\n ```python\n LDAP_AUTH = True\n LDAP_USE_TLS = True\n LDAP_BIND_URI = \"ldaps://dc.corp.example.com\"\n ```\n\n2. Intercept the LDAP connection using a TLS proxy (e.g., `mitmproxy` or `stunnel`):\n ```bash\n # Generate a self-signed certificate\n openssl req -x509 -newkey rsa:2048 -keyout mitm.key -out mitm.crt -days 1 -nodes -subj \"/CN=mitm\"\n\n # Proxy LDAP traffic\n stunnel -d 0.0.0.0:636 -r real-ldap-server:636 -p mitm.pem\n ```\n\n3. Point Lemur\u0027s `LDAP_BIND_URI` at the proxy (or perform ARP spoofing/DNS hijacking)\n\n4. Observe that Lemur connects without any certificate verification error\n\n5. All credentials are visible in the proxy\u0027s TLS session\n\n### Remediation\n\nRemove the global TLS verification bypass and default to strict verification:\n\n```python\nif self.ldap_use_tls:\n # Use instance-level option, not global\n self.ldap_client.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_DEMAND)\n self.ldap_client.set_option(ldap.OPT_PROTOCOL_VERSION, 3)\n if self.ldap_cacert_file:\n self.ldap_client.set_option(ldap.OPT_X_TLS_CACERTFILE, self.ldap_cacert_file)\n```\n\nIf backward compatibility is needed, make it configurable with a secure default:\n\n```python\ntls_require_cert = current_app.config.get(\"LDAP_TLS_REQUIRE_CERT\", ldap.OPT_X_TLS_DEMAND)\nself.ldap_client.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, tls_require_cert)\n```\n\n### Resources\n\n- CWE-295: https://cwe.mitre.org/data/definitions/295.html\n- python-ldap TLS documentation: https://www.python-ldap.org/en/python-ldap-3.4.0/reference/ldap.html#tls-options",
"id": "GHSA-vr7c-r5gj-j3w5",
"modified": "2026-05-13T16:41:37Z",
"published": "2026-05-06T18:48:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/security/advisories/GHSA-vr7c-r5gj-j3w5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44305"
},
{
"type": "PACKAGE",
"url": "https://github.com/Netflix/lemur"
},
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/releases/tag/v1.9.0"
},
{
"type": "WEB",
"url": "https://www.python-ldap.org/en/python-ldap-3.4.0/reference/ldap.html#tls-options"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Lemur: LDAP Authentication Globally Disables TLS Certificate Verification When LDAP_USE_TLS Is Enabled"
}
Mitigation
Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
Mitigation
If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.
CAPEC-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-475: Signature Spoofing by Improper Validation
An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.