CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
1914 vulnerabilities reference this CWE, most recent first.
GHSA-HX3X-MQ59-GR7F
Vulnerability from github – Published: 2022-05-17 02:39 – Updated: 2025-04-20 03:39The First Citizens Community Bank fccb/id809930960 app 3.0.1 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-9563"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-16T12:29:00Z",
"severity": "MODERATE"
},
"details": "The First Citizens Community Bank fccb/id809930960 app 3.0.1 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-hx3x-mq59-gr7f",
"modified": "2025-04-20T03:39:12Z",
"published": "2022-05-17T02:39:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9563"
},
{
"type": "WEB",
"url": "https://medium.com/%40chronic_9612/advisory-44-credit-union-apps-for-ios-may-allow-login-credential-exposure-4d2f380b85c5"
},
{
"type": "WEB",
"url": "https://medium.com/@chronic_9612/advisory-44-credit-union-apps-for-ios-may-allow-login-credential-exposure-4d2f380b85c5"
}
],
"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-HXCJ-GVXH-8944
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11In GNOME libgfbgraph through 0.2.4, gfbgraph-photo.c does not enable TLS certificate verification on the SoupSessionSync objects it creates, leaving users vulnerable to network MITM attacks. NOTE: this is similar to CVE-2016-20011.
{
"affected": [],
"aliases": [
"CVE-2021-39358"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-22T19:15:00Z",
"severity": "MODERATE"
},
"details": "In GNOME libgfbgraph through 0.2.4, gfbgraph-photo.c does not enable TLS certificate verification on the SoupSessionSync objects it creates, leaving users vulnerable to network MITM attacks. NOTE: this is similar to CVE-2016-20011.",
"id": "GHSA-hxcj-gvxh-8944",
"modified": "2022-05-24T19:11:52Z",
"published": "2022-05-24T19:11:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39358"
},
{
"type": "WEB",
"url": "https://blogs.gnome.org/mcatanzaro/2021/05/25/reminder-soupsessionsync-and-soupsessionasync-default-to-no-tls-certificate-verification"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/libgfbgraph/-/issues/17"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GRCVZUNPTNFQQQCEZVP7RYY6OKHPDBC5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UYI47UX6S5PAOWVWQ2KID64MCTXTH7SE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WXXAF56BYLSES4UCLXKFCODZXTNAZ2G6"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HXP5-8PGQ-MGV9
Vulnerability from github – Published: 2021-04-22 16:14 – Updated: 2021-04-21 20:27"HttpUtils#getURLConnection method disables explicitly hostname verification for HTTPS connections making clients vulnerable to man-in-the-middle attacks. Calcite uses this method internally to connect with Druid and Splunk so information leakage may happen when using the respective Calcite adapters. The method itself is in a utility class so people may use it to create vulnerable HTTPS connections for other applications. From Apache Calcite 1.26 onwards, the hostname verification will be performed using the default JVM truststore."
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.calcite:calcite-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.26.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.calcite:calcite-druid"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.26.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.calcite:calcite-splunk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-13955"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-21T20:27:19Z",
"nvd_published_at": "2020-10-09T13:15:00Z",
"severity": "MODERATE"
},
"details": "\"HttpUtils#getURLConnection method disables explicitly hostname verification for HTTPS connections making clients vulnerable to man-in-the-middle attacks. Calcite uses this method internally to connect with Druid and Splunk so information leakage may happen when using the respective Calcite adapters. The method itself is in a utility class so people may use it to create vulnerable HTTPS connections for other applications. From Apache Calcite 1.26 onwards, the hostname verification will be performed using the default JVM truststore.\"",
"id": "GHSA-hxp5-8pgq-mgv9",
"modified": "2021-04-21T20:27:19Z",
"published": "2021-04-22T16:14:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13955"
},
{
"type": "WEB",
"url": "https://github.com/apache/calcite/commit/43eeafcbac29d02c72bd520c003cdfc571de2d15"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/CALCITE-4298"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0b0fbe2038388175951ce1028182d980f9e9a7328be13d52dab70bb3%40%3Cdev.calcite.apache.org%3E"
}
],
"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": "Missing Authentication for Critical Function in Apache Calcite"
}
GHSA-J262-JH5J-P4FW
Vulnerability from github – Published: 2026-07-20 21:31 – Updated: 2026-07-21 00:30Improper certificate validation in Apache MINA SSHD (server-side). Apache MINA SSHD is a Java library for client-side and server-side SSH.
Server-side OpenSSH user certificate validation during user authentication in an Apache MINA SSHD server did not check for the unsupported force-command or verify-required options that could be embedded in the certificate, nor did it validate these options. As a result it was possible that a user could authenticate with such a certificate that included a force-command option but still was able to execute other commands. What other command exactly would be available to the user depends on the implementation of the server.
This issue is fixed in Apache MINA SSHD 2.19.0 and 3.0.0-M5. Applications are advised to upgrade to these versions.
The fix rejects OpenSSH user certificates that include these options, since Apache MINA SSHD implements neither force-command nor sk-*-cert-v01@openssh.com user certificates (which are the only ones for which verify-required would make sense).
{
"affected": [],
"aliases": [
"CVE-2026-56624"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-20T21:16:49Z",
"severity": "HIGH"
},
"details": "Improper certificate validation in Apache MINA SSHD (server-side).\u00a0Apache MINA SSHD is a Java library for client-side and server-side SSH.\n\n\n\n\nServer-side OpenSSH user certificate validation during user authentication in an Apache MINA SSHD server did not check for the unsupported force-command or verify-required options that could be embedded in the certificate, nor did it validate these options. As a result it was possible that a user could authenticate with such a certificate that included a force-command option but still was able to execute other commands. What other command exactly would be available to the user depends on the implementation of the server.\n\n\n\n\nThis issue is fixed in Apache MINA SSHD 2.19.0 and 3.0.0-M5. Applications are advised to upgrade to these versions.\n\n\n\n\nThe fix rejects OpenSSH user certificates that include these options, since Apache MINA SSHD implements neither force-command nor sk-*-cert-v01@openssh.com user certificates (which are the only ones for which verify-required would make sense).",
"id": "GHSA-j262-jh5j-p4fw",
"modified": "2026-07-21T00:30:28Z",
"published": "2026-07-20T21:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56624"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/o4c2jml522j3z80gbryqzc2f1253ltp6"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/20/17"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J357-MFHX-P456
Vulnerability from github – Published: 2022-05-14 03:32 – Updated: 2022-05-14 03:32The verify_certificate function in lib/vtls/schannel.c in libcurl 7.30.0 through 7.51.0, when built for Windows CE using the schannel TLS backend, makes it easier for remote attackers to conduct man-in-the-middle attacks via a crafted wildcard SAN in a server certificate, as demonstrated by "*.com."
{
"affected": [],
"aliases": [
"CVE-2016-9952"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-12T21:29:00Z",
"severity": "HIGH"
},
"details": "The verify_certificate function in lib/vtls/schannel.c in libcurl 7.30.0 through 7.51.0, when built for Windows CE using the schannel TLS backend, makes it easier for remote attackers to conduct man-in-the-middle attacks via a crafted wildcard SAN in a server certificate, as demonstrated by \"*.com.\"",
"id": "GHSA-j357-mfhx-p456",
"modified": "2022-05-14T03:32:30Z",
"published": "2022-05-14T03:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9952"
},
{
"type": "WEB",
"url": "https://curl.haxx.se/CVE-2016-9952.patch"
},
{
"type": "WEB",
"url": "https://curl.haxx.se/docs/adv_20161221B.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J396-CQXP-9QRM
Vulnerability from github – Published: 2022-05-17 02:20 – Updated: 2022-05-17 02:20The RBB SPEED TEST App for Android version 2.0.3 and earlier, RBB SPEED TEST App for iOS version 2.1.0 and earlier 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-2278"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-02T16:29:00Z",
"severity": "MODERATE"
},
"details": "The RBB SPEED TEST App for Android version 2.0.3 and earlier, RBB SPEED TEST App for iOS version 2.1.0 and earlier 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-j396-cqxp-9qrm",
"modified": "2022-05-17T02:20:07Z",
"published": "2022-05-17T02:20:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2278"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN24238648/index.html"
},
{
"type": "WEB",
"url": "http://www.iid.co.jp/information/170714.html"
}
],
"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-J3F7-7RMC-6WQJ
Vulnerability from github – Published: 2021-11-24 20:35 – 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 macOS systems. Additionally, SNI validation is also not enabled when the CA has been "overridden". 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 address this behavior. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.7.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.14.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.6.0 on macOS. Amazon Web Services AWS-C-IO 0.10.7 on macOS.
{
"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.6.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "awsiotsdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-40831"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-24T20:23:57Z",
"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 macOS systems. Additionally, SNI validation is also not enabled when the CA has been \"overridden\". 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 `aws_tls_ctx_options_override_default_trust_store_*` function within the aws-c-io submodule has been updated to address this behavior. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.7.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.14.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.6.0 on macOS. Amazon Web Services AWS-C-IO 0.10.7 on macOS.",
"id": "GHSA-j3f7-7rmc-6wqj",
"modified": "2024-11-18T16:26:17Z",
"published": "2021-11-24T20:35:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40831"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-java-v2/commit/46375e9b1bfb34109b9ff3b1eff9c770f9daa186"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-js-v2/commit/22f1989f5bdb0bdd9c912a5a2d255ee6c0854f68"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-python-v2/commit/5aef82573202309063eb540b72cee0e565f85a2d"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-j3f7-7rmc-6wqj"
},
{
"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-864.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-J3P7-VMJW-MH56
Vulnerability from github – Published: 2022-05-13 01:33 – Updated: 2022-05-13 01:33IBM Security Guardium EcoSystem 10.5 does not validate, or incorrectly validates, a certificate.This weakness might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host. IBM X-Force ID: 141417.
{
"affected": [],
"aliases": [
"CVE-2018-1509"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-02T15:29:00Z",
"severity": "HIGH"
},
"details": "IBM Security Guardium EcoSystem 10.5 does not validate, or incorrectly validates, a certificate.This weakness might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host. IBM X-Force ID: 141417.",
"id": "GHSA-j3p7-vmjw-mh56",
"modified": "2022-05-13T01:33:10Z",
"published": "2022-05-13T01:33:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1509"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/141417"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=ibm10730321"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1041759"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J3QW-G67Q-7M64
Vulnerability from github – Published: 2022-09-25 00:00 – Updated: 2022-09-30 04:26Apache Pulsar Brokers and Proxies create an internal Pulsar Admin Client that does not verify peer TLS certificates, even when tlsAllowInsecureConnection is disabled via configuration. The Pulsar Admin Client's intra-cluster and geo-replication HTTPS connections are vulnerable to man in the middle attacks, which could leak authentication data, configuration data, and any other data sent by these clients. 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. This issue affects Apache Pulsar Broker and Proxy 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-broker"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-broker"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.8.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.8.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-broker"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-broker"
},
"ranges": [
{
"events": [
{
"introduced": "2.10.0"
},
{
"fixed": "2.10.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.10.0"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "2.10.0"
},
{
"fixed": "2.10.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.10.0"
]
}
],
"aliases": [
"CVE-2022-33683"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T04:26:00Z",
"nvd_published_at": "2022-09-23T10:15:00Z",
"severity": "MODERATE"
},
"details": "Apache Pulsar Brokers and Proxies create an internal Pulsar Admin Client that does not verify peer TLS certificates, even when tlsAllowInsecureConnection is disabled via configuration. The Pulsar Admin Client\u0027s intra-cluster and geo-replication HTTPS connections are vulnerable to man in the middle attacks, which could leak authentication data, configuration data, and any other data sent by these clients. 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. This issue affects Apache Pulsar Broker and Proxy 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-j3qw-g67q-7m64",
"modified": "2022-09-30T04:26:00Z",
"published": "2022-09-25T00:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33683"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/42v5rsxj36r3nhfxhmhb2x12r5jmvx3x"
}
],
"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 Brokers and Proxies vulnerable to Improper Certificate Validation"
}
GHSA-J3R3-Q9V5-GG3H
Vulnerability from github – Published: 2025-11-17 18:30 – Updated: 2025-11-17 18:30GoSign Desktop through 2.4.1 disables TLS certificate validation when configured to use a proxy server. This can be problematic if the GoSign Desktop user selects an arbitrary proxy server without consideration of whether outbound HTTPS connections from the proxy server to Internet servers succeed even for untrusted or invalid server certificates. In this scenario (which is outside of the product's design objectives), integrity protection could be bypassed. In typical cases of a proxy server for outbound HTTPS traffic from an enterprise, those connections would not succeed. (Admittedly, the usual expectation is that a client application is configured to trust an enterprise CA and does not set SSL_VERIFY_NONE.) Also, it is of course unsafe to place ~/.gosign in the home directory of an untrusted user and then have other users execute downloaded files.
{
"affected": [],
"aliases": [
"CVE-2025-65083"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-17T16:15:51Z",
"severity": "LOW"
},
"details": "GoSign Desktop through 2.4.1 disables TLS certificate validation when configured to use a proxy server. This can be problematic if the GoSign Desktop user selects an arbitrary proxy server without consideration of whether outbound HTTPS connections from the proxy server to Internet servers succeed even for untrusted or invalid server certificates. In this scenario (which is outside of the product\u0027s design objectives), integrity protection could be bypassed. In typical cases of a proxy server for outbound HTTPS traffic from an enterprise, those connections would not succeed. (Admittedly, the usual expectation is that a client application is configured to trust an enterprise CA and does not set SSL_VERIFY_NONE.) Also, it is of course unsafe to place ~/.gosign in the home directory of an untrusted user and then have other users execute downloaded files.",
"id": "GHSA-j3r3-q9v5-gg3h",
"modified": "2025-11-17T18:30:30Z",
"published": "2025-11-17T18:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65083"
},
{
"type": "WEB",
"url": "https://securityaffairs.com/184672/hacking/multiple-vulnerabilities-in-gosign-desktop-lead-to-remote-code-execution.html"
},
{
"type": "WEB",
"url": "https://www.firma.infocert.it/prodotti/gosign"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:L/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.