CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
2267 vulnerabilities reference this CWE, most recent first.
GHSA-4WJ3-7P36-WMRW
Vulnerability from github – Published: 2024-05-08 15:30 – Updated: 2025-08-28 21:31An improper certificate validation vulnerability exists in BIG-IP Next Central Manager and may allow an attacker to impersonate an Instance Provider system. A successful exploit of this vulnerability can allow the attacker to cross a security boundary. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
{
"affected": [],
"aliases": [
"CVE-2024-33612"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-08T15:15:11Z",
"severity": "MODERATE"
},
"details": "\n\n\nAn improper certificate validation vulnerability exists in BIG-IP Next Central Manager and may allow an attacker to impersonate an Instance Provider system. A successful exploit of this vulnerability can allow the attacker to cross a security boundary.\u00a0\u00a0Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.\n\n",
"id": "GHSA-4wj3-7p36-wmrw",
"modified": "2025-08-28T21:31:24Z",
"published": "2024-05-08T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33612"
},
{
"type": "WEB",
"url": "https://my.f5.com/manage/s/article/K000139012"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4WMW-P7M3-H442
Vulnerability from github – Published: 2026-10-09 09:31 – Updated: 2026-10-09 09:31Dell Secure Connect Gateway (SCG) Policy Manager, versions prior to 5.34.00.16, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Denial of service, Information disclosure, and Remote execution.
{
"affected": [],
"aliases": [
"CVE-2026-78020"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-09T09:17:09Z",
"severity": "HIGH"
},
"details": "Dell Secure Connect Gateway (SCG) Policy Manager, versions prior to 5.34.00.16, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Denial of service, Information disclosure, and Remote execution.",
"id": "GHSA-4wmw-p7m3-h442",
"modified": "2026-10-09T09:31:06Z",
"published": "2026-10-09T09:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78020"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-ca/000503592/dsa-2026-385-security-update-for-dell-secure-connect-gateway-policy-manager-multiple-vulnerabilities?msockid=3021cac2195069ed3194ddad186a68f9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4WMW-X67R-QXGQ
Vulnerability from github – Published: 2026-08-11 15:32 – Updated: 2026-08-11 15:32Cleartext transmission of sensitive information in the Core of Ivanti Endpoint Manager before version 2024 SU7 allows a remote unauthenticated attacker in a MITM position to leak credentials for external SQL connections.
{
"affected": [],
"aliases": [
"CVE-2026-18129"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T15:17:28Z",
"severity": "HIGH"
},
"details": "Cleartext transmission of sensitive information in the Core of Ivanti Endpoint Manager before version 2024 SU7 allows a remote unauthenticated attacker in a MITM position to leak credentials for external SQL connections.",
"id": "GHSA-4wmw-x67r-qxgq",
"modified": "2026-08-11T15:32:45Z",
"published": "2026-08-11T15:32:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18129"
},
{
"type": "WEB",
"url": "https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-EPM-August-2026"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-4WPW-HPQ9-3GCX
Vulnerability from github – Published: 2022-10-11 12:00 – Updated: 2022-10-12 19:00A vulnerability has been identified in Industrial Edge Management (All versions < V1.5.1). The affected software does not properly validate the server certificate when initiating a TLS connection. This could allow an attacker to spoof a trusted entity by interfering in the communication path between the client and the intended server.
{
"affected": [],
"aliases": [
"CVE-2022-40147"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-11T11:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in Industrial Edge Management (All versions \u003c V1.5.1). The affected software does not properly validate the server certificate when initiating a TLS connection. This could allow an attacker to spoof a trusted entity by interfering in the communication path between the client and the intended server.",
"id": "GHSA-4wpw-hpq9-3gcx",
"modified": "2022-10-12T19:00:39Z",
"published": "2022-10-11T12:00:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40147"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-649853.pdf"
}
],
"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"
}
]
}
GHSA-4WR6-X9G6-M47V
Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-05-24 17:48HashiCorp Vault and Vault Enterprise Cassandra integrations (storage backend and database secrets engine plugin) did not validate TLS certificates when connecting to Cassandra clusters. Fixed in 1.6.4 and 1.7.1
{
"affected": [],
"aliases": [
"CVE-2021-27400"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-22T17:15:00Z",
"severity": "HIGH"
},
"details": "HashiCorp Vault and Vault Enterprise Cassandra integrations (storage backend and database secrets engine plugin) did not validate TLS certificates when connecting to Cassandra clusters. Fixed in 1.6.4 and 1.7.1",
"id": "GHSA-4wr6-x9g6-m47v",
"modified": "2022-05-24T17:48:09Z",
"published": "2022-05-24T17:48:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27400"
},
{
"type": "WEB",
"url": "https://discuss.hashicorp.com/t/hcsec-2021-10-vault-s-cassandra-integrations-did-not-validate-tls-certificates/23463"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4X46-8GG7-F9VX
Vulnerability from github – Published: 2023-10-26 06:30 – Updated: 2023-11-08 15:30It was discovered that when acting as TLS clients, Beats, Elastic Agent, APM Server, and Fleet Server did not verify whether the server certificate is valid for the target IP address; however, certificate signature validation is still performed. More specifically, when the client is configured to connect to an IP address (instead of a hostname) it does not validate the server certificate's IP SAN values against that IP address and certificate validation fails, and therefore the connection is not blocked as expected.
{
"affected": [],
"aliases": [
"CVE-2023-31421"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-26T04:15:16Z",
"severity": "HIGH"
},
"details": "It was discovered that when acting as TLS clients, Beats, Elastic Agent, APM Server, and Fleet Server did not verify whether the server certificate is valid for the target IP address; however, certificate signature validation is still performed. More specifically, when the client is configured to connect to an IP address (instead of a hostname) it does not validate the server certificate\u0027s IP SAN values against that IP address and certificate validation fails, and therefore the connection is not blocked as expected.",
"id": "GHSA-4x46-8gg7-f9vx",
"modified": "2023-11-08T15:30:32Z",
"published": "2023-10-26T06:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31421"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/beats-elastic-agent-apm-server-and-fleet-server-8-10-1-security-update-improper-certificate-validation-issue-esa-2023-16/343385"
},
{
"type": "WEB",
"url": "https://www.elastic.co/community/security"
}
],
"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-4XMJ-XWHR-JCJ2
Vulnerability from github – Published: 2026-10-02 12:31 – Updated: 2026-10-02 12:31Improper Validation of Certificate with Host Mismatch in the C++ and D libraries of Apache Thrift.
Both libraries install a default access manager for client sockets — TSSLSocketFactory does so in C++, and the accessManager property does so in D — which compares the peer certificate against the host
name that was connected to. That comparison walks the subjectAltName dNSName entries first and consults the certificate Common Name afterwards. A name that does not match yields a "skip" result rather than
a rejection, so a certificate whose subjectAltName entries are all present and all non-matching falls through to the Common Name, which can then satisfy the check.
RFC 6125 section 6.4.4, and RFC 9525 section 2, require that the Common Name is not consulted when a dNSName subjectAltName is present. A certificate carrying subjectAltName entries for one name and a
Common Name for another is therefore accepted for a connection to the second name.
Exploitation requires an attacker positioned on the network path who holds a certificate that chains to a certificate authority in the client's trust store and whose Common Name matches the connected host
name. Public certificate authorities have not issued on Common Name alone for many years, so this is principally a concern for deployments using a private or enterprise public-key infrastructure.
This issue affects the C++ library of Apache Thrift from 0.7.0 through 0.24.0 and the D library from 0.9.0 through 0.24.0. Users should upgrade to 0.25.0.
{
"affected": [],
"aliases": [
"CVE-2026-85088"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-02T12:17:21Z",
"severity": "MODERATE"
},
"details": "Improper Validation of Certificate with Host Mismatch in the C++ and D libraries of Apache Thrift.\n\n\n\nBoth libraries install a default access manager for client sockets \u2014 TSSLSocketFactory does so in C++, and the accessManager property does so in D \u2014 which compares the peer certificate against the host\n\nname that was connected to. That comparison walks the subjectAltName dNSName entries first and consults the certificate Common Name afterwards. A name that does not match yields a \"skip\" result rather than\n\na rejection, so a certificate whose subjectAltName entries are all present and all non-matching falls through to the Common Name, which can then satisfy the check.\n\n\n\nRFC 6125 section 6.4.4, and RFC 9525 section 2, require that the Common Name is not consulted when a dNSName subjectAltName is present. A certificate carrying subjectAltName entries for one name and a\n\nCommon Name for another is therefore accepted for a connection to the second name.\n\n\n\nExploitation requires an attacker positioned on the network path who holds a certificate that chains to a certificate authority in the client\u0027s trust store and whose Common Name matches the connected host\n\nname. Public certificate authorities have not issued on Common Name alone for many years, so this is principally a concern for deployments using a private or enterprise public-key infrastructure.\n\n\n\nThis issue affects the C++ library of Apache Thrift from 0.7.0 through 0.24.0 and the D library from 0.9.0 through 0.24.0. Users should upgrade to 0.25.0.",
"id": "GHSA-4xmj-xwhr-jcj2",
"modified": "2026-10-02T12:31:18Z",
"published": "2026-10-02T12:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85088"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/33otcgbqd27wf6qq810q56znzbomnhg1"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/zcgm7lx6037lvgvn87rc1tj3p0zhv371"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4XQV-2FH4-RRC6
Vulnerability from github – Published: 2022-05-17 02:45 – Updated: 2025-04-20 03:37The FOREX.com FOREXTrader for iPhone app 2.9.12 through 2.9.14 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-5912"
],
"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 FOREX.com FOREXTrader for iPhone app 2.9.12 through 2.9.14 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-4xqv-2fh4-rrc6",
"modified": "2025-04-20T03:37:14Z",
"published": "2022-05-17T02:45:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5912"
},
{
"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-5244-5VQH-QWMC
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42ELECOM WRC-300FEBK-S contains an improper certificate validation vulnerability. Via a man-in-the-middle attack, an attacker may alter the communication response. As a result, an arbitrary OS command may be executed on the affected device.
{
"affected": [],
"aliases": [
"CVE-2021-20649"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-12T07:15:00Z",
"severity": "MODERATE"
},
"details": "ELECOM WRC-300FEBK-S contains an improper certificate validation vulnerability. Via a man-in-the-middle attack, an attacker may alter the communication response. As a result, an arbitrary OS command may be executed on the affected device.",
"id": "GHSA-5244-5vqh-qwmc",
"modified": "2022-05-24T17:42:04Z",
"published": "2022-05-24T17:42:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20649"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN47580234/index.html"
},
{
"type": "WEB",
"url": "https://www.elecom.co.jp/news/security/20210126-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-524Q-MW44-GX36
Vulnerability from github – Published: 2025-12-10 21:31 – Updated: 2025-12-11 21:31Due to a lack of certificate validation, all traffic from the mobile application can be intercepted. As a result, an adversary located "upstream" can decrypt the TLS traffic, inspect its contents, and modify the requests in transit. This may result in a total compromise of the user's account if the attacker intercepts a request with active authentication tokens or cracks the MD5 hash sent on login.
{
"affected": [],
"aliases": [
"CVE-2025-65830"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-10T21:16:08Z",
"severity": "CRITICAL"
},
"details": "Due to a lack of certificate validation, all traffic from the mobile application can be intercepted. As a result, an adversary located \"upstream\" can decrypt the TLS traffic, inspect its contents, and modify the requests in transit. This may result in a total compromise of the user\u0027s account if the attacker intercepts a request with active authentication tokens or cracks the MD5 hash sent on login.",
"id": "GHSA-524q-mw44-gx36",
"modified": "2025-12-11T21:31:27Z",
"published": "2025-12-10T21:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65830"
},
{
"type": "WEB",
"url": "https://gist.github.com/dead1nfluence/4dffc239b4a460f41a03345fd8e5feb5#file-lack-of-certificate-pinning-md"
},
{
"type": "WEB",
"url": "https://github.com/dead1nfluence/Meatmeet-Pro-Vulnerabilities/blob/main/Mobile-Application/Lack-of-Certificate-Pinning.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
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.