CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
2417 vulnerabilities reference this CWE, most recent first.
GHSA-C2X3-X977-3V6G
Vulnerability from github – Published: 2022-05-24 22:28 – Updated: 2023-11-07 21:30Summary - The certificate used to identify Orchestrator to EdgeConnect devices is not validated Details: The certificate used to identify Orchestrator to EdgeConnect devices is not validated, which makes it possible for someone to establish a TLS connection from EdgeConnect to an untrusted Orchestrator. Product affected - All versions affected prior to Silver Peak Unity ECOS™ 8.3.2+, 8.1.9.12+ and Silver Peak Unity Orchestrator™ 8.9.2+ 1. Silver Peak product(s) Applicability 2. Unity EdgeConnect, NX, VX Applicable 3. Unity Orchestrator Applicable 4. EdgeConnect in AWS, Azure, GCP Applicable 5. Silver Peak Cloud Services Not Applicable Resolution • Changes have been made to strengthen the initial exchange between the EdgeConnect appliance and the Orchestrator. After the changes, EdgeConnect will validate the certificate used to identify the Orchestrator to EdgeConnect. • TLS itself is continually subject to newly discovered and exploitable vulnerabilities. As such, all versions of EdgeConnect software implement additional out-of-band and user-controlled authentication mechanisms. Any required configuration • Do not change Orchestrator’s IP address as discovered by the EdgeConnect appliance. • Upgrade to Silver Peak Unity ECOS™ 8.3.2+ or 8.1.9.12+ and Silver Peak Unity Orchestrator™ 8.9.2+. • In Orchestrator, enable the “Verify Orchestrator Certificate” option under Advanced Security Settings.
{
"affected": [],
"aliases": [
"CVE-2020-12143"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-05-05T20:15:00Z",
"severity": "MODERATE"
},
"details": "Summary - The certificate used to identify Orchestrator to EdgeConnect devices is not validated Details: The certificate used to identify Orchestrator to EdgeConnect devices is not validated, which makes it possible for someone to establish a TLS connection from EdgeConnect to an untrusted Orchestrator. Product affected - All versions affected prior to Silver Peak Unity ECOS\u2122 8.3.2+, 8.1.9.12+ and Silver Peak Unity Orchestrator\u2122 8.9.2+ 1. Silver Peak product(s) Applicability 2. Unity EdgeConnect, NX, VX Applicable 3. Unity Orchestrator Applicable 4. EdgeConnect in AWS, Azure, GCP Applicable 5. Silver Peak Cloud Services Not Applicable Resolution \u2022 Changes have been made to strengthen the initial exchange between the EdgeConnect appliance and the Orchestrator. After the changes, EdgeConnect will validate the certificate used to identify the Orchestrator to EdgeConnect. \u2022 TLS itself is continually subject to newly discovered and exploitable vulnerabilities. As such, all versions of EdgeConnect software implement additional out-of-band and user-controlled authentication mechanisms. Any required configuration \u2022 Do not change Orchestrator\u2019s IP address as discovered by the EdgeConnect appliance. \u2022 Upgrade to Silver Peak Unity ECOS\u2122 8.3.2+ or 8.1.9.12+ and Silver Peak Unity Orchestrator\u2122 8.9.2+. \u2022 In Orchestrator, enable the \u201cVerify Orchestrator Certificate\u201d option under Advanced Security Settings.",
"id": "GHSA-c2x3-x977-3v6g",
"modified": "2023-11-07T21:30:21Z",
"published": "2022-05-24T22:28:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12143"
},
{
"type": "WEB",
"url": "https://www.silver-peak.com/sites/default/files/advisory/security_advisory_notice_rogue_orchestrator-cve_2020_12143.pdf"
},
{
"type": "WEB",
"url": "https://www.silver-peak.com/sites/default/files/advisory/security_advisory_notice_rogue_orchestrator_cve_2020_12143.pdf"
},
{
"type": "WEB",
"url": "https://www.silver-peak.com/support/user-documentation/security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C35R-WFP8-2J62
Vulnerability from github – Published: 2022-05-24 16:50 – Updated: 2024-04-04 01:17A vulnerability in the Web Services Management Agent (WSMA) feature of Cisco Industrial Network Director (IND) could allow an unauthenticated, remote attacker to gain unauthorized read access to sensitive data using an invalid X.509 certificate. The vulnerability is due to insufficient X.509 certificate validation when establishing a WSMA connection. An attacker could exploit this vulnerability by supplying a crafted X.509 certificate during the WSMA connection setup phase. A successful exploit could allow the attacker to conduct man-in-the-middle attacks to decrypt confidential information on WSMA connections to the affected software. At the time of publication, this vulnerability affected Cisco IND Software releases prior to 1.7.
{
"affected": [],
"aliases": [
"CVE-2019-1940"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-17T21:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the Web Services Management Agent (WSMA) feature of Cisco Industrial Network Director (IND) could allow an unauthenticated, remote attacker to gain unauthorized read access to sensitive data using an invalid X.509 certificate. The vulnerability is due to insufficient X.509 certificate validation when establishing a WSMA connection. An attacker could exploit this vulnerability by supplying a crafted X.509 certificate during the WSMA connection setup phase. A successful exploit could allow the attacker to conduct man-in-the-middle attacks to decrypt confidential information on WSMA connections to the affected software. At the time of publication, this vulnerability affected Cisco IND Software releases prior to 1.7.",
"id": "GHSA-c35r-wfp8-2j62",
"modified": "2024-04-04T01:17:57Z",
"published": "2022-05-24T16:50:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1940"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190717-wsma-info"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/109296"
}
],
"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-C46X-8Q9C-R3VX
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2025-07-23 15:31A vulnerability in the Cisco Identity Services Engine (ISE) integration feature of the Cisco DNA Center Software could allow an unauthenticated, remote attacker to gain unauthorized access to sensitive data. The vulnerability is due to an incomplete validation of the X.509 certificate used when establishing a connection between DNA Center and an ISE server. An attacker could exploit this vulnerability by supplying a crafted certificate and could then intercept communications between the ISE and DNA Center. A successful exploit could allow the attacker to view and alter sensitive information that the ISE maintains about clients that are connected to the network.
{
"affected": [],
"aliases": [
"CVE-2021-1134"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-29T03:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the Cisco Identity Services Engine (ISE) integration feature of the Cisco DNA Center Software could allow an unauthenticated, remote attacker to gain unauthorized access to sensitive data. The vulnerability is due to an incomplete validation of the X.509 certificate used when establishing a connection between DNA Center and an ISE server. An attacker could exploit this vulnerability by supplying a crafted certificate and could then intercept communications between the ISE and DNA Center. A successful exploit could allow the attacker to view and alter sensitive information that the ISE maintains about clients that are connected to the network.",
"id": "GHSA-c46x-8q9c-r3vx",
"modified": "2025-07-23T15:31:07Z",
"published": "2022-05-24T19:06:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1134"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-dnac-certvalid-USEj2CZk"
}
],
"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-C4FC-CX58-4V39
Vulnerability from github – Published: 2022-05-14 01:02 – Updated: 2022-05-14 01:02Sennheiser HeadSetup 7.3.4903 places Certification Authority (CA) certificates into the Trusted Root CA store of the local system, and publishes the private key in the SennComCCKey.pem file within the public software distribution, which allows remote attackers to spoof arbitrary web sites or software publishers for several years, even if the HeadSetup product is uninstalled. NOTE: a vulnerability-assessment approach must check all Windows systems for CA certificates with a CN of 127.0.0.1 or SennComRootCA, and determine whether those certificates are unwanted.
{
"affected": [],
"aliases": [
"CVE-2018-17612"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-09T21:29:00Z",
"severity": "HIGH"
},
"details": "Sennheiser HeadSetup 7.3.4903 places Certification Authority (CA) certificates into the Trusted Root CA store of the local system, and publishes the private key in the SennComCCKey.pem file within the public software distribution, which allows remote attackers to spoof arbitrary web sites or software publishers for several years, even if the HeadSetup product is uninstalled. NOTE: a vulnerability-assessment approach must check all Windows systems for CA certificates with a CN of 127.0.0.1 or SennComRootCA, and determine whether those certificates are unwanted.",
"id": "GHSA-c4fc-cx58-4v39",
"modified": "2022-05-14T01:02:20Z",
"published": "2022-05-14T01:02:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17612"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180029"
},
{
"type": "WEB",
"url": "https://www.secorvo.de/publikationen/headsetup-vulnerability-report-secorvo-2018.pdf"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106045"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C4RH-4376-GFF4
Vulnerability from github – Published: 2021-11-24 21:12 – Updated: 2024-11-18 16:26The AWS IoT Device SDK v2 for Java, Python, C++ and Node.js appends a user supplied Certificate Authority (CA) to the root CAs instead of overriding it on Unix systems. TLS handshakes will thus succeed if the peer can be verified either from the user-supplied CA or the system’s default trust-store. Attackers with access to a host’s trust stores or are able to compromise a certificate authority already in the host's trust store (note: the attacker must also be able to spoof DNS in this case) may be able to use this issue to bypass CA pinning. An attacker could then spoof the MQTT broker, and either drop traffic and/or respond with the attacker's data, but they would not be able to forward this data on to the MQTT broker because the attacker would still need the user's private keys to authenticate against the MQTT broker. The 'aws_tls_ctx_options_override_default_trust_store_*' function within the aws-c-io submodule has been updated to override the default trust store. This corrects this issue. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.6.1 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.12.7 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.5.3 on Linux/Unix. Amazon Web Services AWS-C-IO 0.10.4 on Linux/Unix.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "software.amazon.awssdk.iotdevicesdk:aws-iot-device-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "aws-iot-device-sdk-v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "awsiotsdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-40830"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-24T20:28:03Z",
"nvd_published_at": "2021-11-23T00:15:00Z",
"severity": "HIGH"
},
"details": "The AWS IoT Device SDK v2 for Java, Python, C++ and Node.js appends a user supplied Certificate Authority (CA) to the root CAs instead of overriding it on Unix systems. TLS handshakes will thus succeed if the peer can be verified either from the user-supplied CA or the system\u2019s default trust-store. Attackers with access to a host\u2019s trust stores or are able to compromise a certificate authority already in the host\u0027s trust store (note: the attacker must also be able to spoof DNS in this case) may be able to use this issue to bypass CA pinning. An attacker could then spoof the MQTT broker, and either drop traffic and/or respond with the attacker\u0027s data, but they would not be able to forward this data on to the MQTT broker because the attacker would still need the user\u0027s private keys to authenticate against the MQTT broker. The \u0027aws_tls_ctx_options_override_default_trust_store_*\u0027 function within the aws-c-io submodule has been updated to override the default trust store. This corrects this issue. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.6.1 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.12.7 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.5.3 on Linux/Unix. Amazon Web Services AWS-C-IO 0.10.4 on Linux/Unix.",
"id": "GHSA-c4rh-4376-gff4",
"modified": "2024-11-18T16:26:17Z",
"published": "2021-11-24T21:12:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40830"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-java-v2/commit/67950ad2a02f2f9355c310b69dc9226b017f32f2"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-js-v2/commit/53a36e3ac203291494120604d416b6de59177cac"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-python-v2/commit/0450ce68add7e3d05c6d781ecdac953c299c053a"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-c4rh-4376-gff4"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-cpp-v2"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-java-v2"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-js-v2"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-python-v2"
},
{
"type": "WEB",
"url": "https://github.com/awslabs/aws-c-io"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/awsiotsdk/PYSEC-2021-863.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Improper certificate management in AWS IoT Device SDK v2"
}
GHSA-C597-F74M-JGC2
Vulnerability from github – Published: 2022-02-09 00:56 – Updated: 2021-04-01 21:57A flaw was found in Keycloak in versions before 10.0.0, where it does not perform the TLS hostname verification while sending emails using the SMTP server. This flaw allows an attacker to perform a man-in-the-middle (MITM) attack.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-parent"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-1758"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-297"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-01T21:57:32Z",
"nvd_published_at": "2020-05-15T19:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Keycloak in versions before 10.0.0, where it does not perform the TLS hostname verification while sending emails using the SMTP server. This flaw allows an attacker to perform a man-in-the-middle (MITM) attack.",
"id": "GHSA-c597-f74m-jgc2",
"modified": "2021-04-01T21:57:32Z",
"published": "2022-02-09T00:56:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1758"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-1758"
},
{
"type": "WEB",
"url": "https://issues.redhat.com/browse/KEYCLOAK-13285"
}
],
"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"
}
],
"summary": "Improper Certificate Validation and Improper Validation of Certificate with Host Mismatch in Keycloak"
}
GHSA-C5CJ-HMH6-45PV
Vulnerability from github – Published: 2025-02-20 06:31 – Updated: 2025-03-11 15:30IBM OpenPages with Watson 8.3 and 9.0
could allow a remote attacker to spoof mail server identity when using SSL/TLS security. An attacker could exploit this vulnerability to gain access to sensitive information disclosed through email notifications generated by OpenPages or disrupt notification delivery.
{
"affected": [],
"aliases": [
"CVE-2024-49782"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-297"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-20T04:15:10Z",
"severity": "MODERATE"
},
"details": "IBM OpenPages with Watson 8.3 and 9.0\u00a0\n\n\n\ncould allow a remote attacker to spoof mail server identity when using SSL/TLS security. An attacker could exploit this vulnerability to gain access to sensitive information disclosed through email notifications generated by OpenPages or disrupt notification delivery.",
"id": "GHSA-c5cj-hmh6-45pv",
"modified": "2025-03-11T15:30:57Z",
"published": "2025-02-20T06:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49782"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7183541"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C5FP-X2H5-VJV7
Vulnerability from github – Published: 2022-09-25 00:00 – Updated: 2022-09-30 00:00Delayed TLS hostname verification in the Pulsar Java Client and the Pulsar Proxy make each client vulnerable to a man in the middle attack. Connections from the Pulsar Java Client to the Pulsar Broker/Proxy and connections from the Pulsar Proxy to the Pulsar Broker are vulnerable. Authentication data is sent before verifying the server’s TLS certificate matches the hostname, which means authentication data could be exposed to an attacker. An attacker can only take advantage of this vulnerability by taking control of a machine 'between' the client and the server. The attacker must then actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host. Because the client sends authentication data before performing hostname verification, an attacker could gain access to the client’s authentication data. The client eventually closes the connection when it verifies the hostname and identifies the targeted hostname does not match a hostname on the certificate. Because the client eventually closes the connection, the value of the intercepted authentication data depends on the authentication method used by the client. Token based authentication and username/password authentication methods are vulnerable because the authentication data can be used to impersonate the client in a separate session. This issue affects Apache Pulsar Java Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; 2.6.4 and earlier.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-client"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.8.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.10.0"
},
{
"fixed": "2.10.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.10.0"
]
}
],
"aliases": [
"CVE-2022-33681"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T00:00:47Z",
"nvd_published_at": "2022-09-23T10:15:00Z",
"severity": "MODERATE"
},
"details": "Delayed TLS hostname verification in the Pulsar Java Client and the Pulsar Proxy make each client vulnerable to a man in the middle attack. Connections from the Pulsar Java Client to the Pulsar Broker/Proxy and connections from the Pulsar Proxy to the Pulsar Broker are vulnerable. Authentication data is sent before verifying the server\u2019s TLS certificate matches the hostname, which means authentication data could be exposed to an attacker. An attacker can only take advantage of this vulnerability by taking control of a machine \u0027between\u0027 the client and the server. The attacker must then actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host. Because the client sends authentication data before performing hostname verification, an attacker could gain access to the client\u2019s authentication data. The client eventually closes the connection when it verifies the hostname and identifies the targeted hostname does not match a hostname on the certificate. Because the client eventually closes the connection, the value of the intercepted authentication data depends on the authentication method used by the client. Token based authentication and username/password authentication methods are vulnerable because the authentication data can be used to impersonate the client in a separate session. This issue affects Apache Pulsar Java Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; 2.6.4 and earlier.",
"id": "GHSA-c5fp-x2h5-vjv7",
"modified": "2022-09-30T00:00:47Z",
"published": "2022-09-25T00:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33681"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/pulsar/tree/db26073728bf86fc80deecaece2dc02b50bbb9b5/pulsar-client"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/fpo6x10trvn20hlk0dmnr5vlz5v4kl3d"
}
],
"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"
}
],
"summary": "Apache Pulsar Java Client vulnerable to Improper Certificate Validation"
}
GHSA-C5J4-P43C-GH65
Vulnerability from github – Published: 2026-10-29 18:30 – Updated: 2026-10-29 18:30Szafir accepts any client or server certificate without performing certificate and hostname validation, allowing HTTPS connections without authenticating the remote server. An attacker can provide an arbitrary SSL/TLS certificate and cause the application to download an update file from their server.
This issue was fixed in version 2.0 build 708.
{
"affected": [],
"aliases": [
"CVE-2026-106036"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-29T16:17:47Z",
"severity": "MODERATE"
},
"details": "Szafir accepts any client or server certificate without performing certificate and hostname validation, allowing HTTPS connections without authenticating the remote server. An attacker can provide an arbitrary SSL/TLS certificate and cause the application to download an update file from their server.\n\n\n\nThis issue was fixed in version\u00a02.0 build 708.",
"id": "GHSA-c5j4-p43c-gh65",
"modified": "2026-10-29T18:30:50Z",
"published": "2026-10-29T18:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106036"
},
{
"type": "WEB",
"url": "https://cert.pl/posts/2026/10/CVE-2026-93570"
},
{
"type": "WEB",
"url": "https://www.elektronicznypodpis.pl"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/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-C5WM-WJMG-6V8P
Vulnerability from github – Published: 2022-07-07 00:00 – Updated: 2022-07-15 00:00A insecure configuration for certificate verification (http.verify_mode = OpenSSL::SSL::VERIFY_NONE) may lead to verification bypass in Red Hat CloudForms 5.x.
{
"affected": [],
"aliases": [
"CVE-2014-8164"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-06T20:15:00Z",
"severity": "CRITICAL"
},
"details": "A insecure configuration for certificate verification (http.verify_mode = OpenSSL::SSL::VERIFY_NONE) may lead to verification bypass in Red Hat CloudForms 5.x.",
"id": "GHSA-c5wm-wjmg-6v8p",
"modified": "2022-07-15T00:00:23Z",
"published": "2022-07-07T00:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-8164"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1151208"
}
],
"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.