Common Weakness Enumeration

CWE-295

Allowed

Improper 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:39
VLAI
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.

Show details on source website

{
  "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:11
VLAI
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.

Show details on source website

{
  "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
VLAI
Summary
Missing Authentication for Critical Function in Apache Calcite
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."

Show details on source website

{
  "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:30
VLAI
Details

Improper 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).

Show details on source website

{
  "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:32
VLAI
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."

Show details on source website

{
  "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:20
VLAI
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.

Show details on source website

{
  "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:26
VLAI
Summary
Improper certificate management in AWS IoT Device SDK v2
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’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.

Show details on source website

{
  "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:33
VLAI
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.

Show details on source website

{
  "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:26
VLAI
Summary
Apache Pulsar Brokers and Proxies vulnerable to Improper Certificate Validation
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'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.

Show details on source website

{
  "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:30
VLAI
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'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.

Show details on source website

{
  "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
Architecture and Design Implementation

Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

Mitigation
Implementation

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.