GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not validate, or incorrectly validates, a certificate.

2155 vulnerabilities reference this CWE, most recent first.

GHSA-3Q49-H8F9-9FR9

Vulnerability from github – Published: 2020-07-31 17:39 – Updated: 2023-05-16 16:03
VLAI
Summary
Missing TLS certificate verification
Details

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use the EM::Connection#start_tls method in EventMachine to implement the TLS handshake whenever a wss: URL is used for the connection. This method does not implement certificate verification by default, meaning that it does not check that the server presents a valid and trusted TLS certificate for the expected hostname. That means that any https: or wss: connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.

The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.

This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification in their own codebase; although EventMachine does not implement certificate verification itself, it provides an extension point for the caller to implement it, called ssl_verify_peer. Based on this implementation, we have incorporated similar functionality into faye-websocket.

After implementing verification in v1.1.6, em-http-request has elected to leave the :verify_peer option switched off by default. We have decided to enable this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:

  • talking to the expected server, and will not break under this change
  • being attacked, and would benefit from being alerted to this fact
  • deliberately talking to a server that would be rejected by verification

The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.

We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:

client = Faye::Client.new('https://example.com/', tls: { verify_peer: false })

Unfortunately we can't offer an equivalent of the :root_cert_file option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.

The same functionality is now supported in the Node.js version, with a tls option whose values will be passed to the https and tls modules as appropriate when making connections. For example, you can provide your own CA certificate:

var client = new faye.Client('https://example.com/', {
  tls: {
    ca: fs.readFileSync('path/to/certificate.pem')
  }
});

For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

Severity
8.0 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "faye"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-07-31T17:38:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Faye uses [em-http-request][6] and [faye-websocket][10] in the Ruby version of its client. Those libraries both use the [`EM::Connection#start_tls`][1] method in [EventMachine][2] to implement the TLS handshake whenever a `wss:` URL is used for the connection. This method does not implement certificate verification by default, meaning that it does not check that the server presents a valid and trusted TLS certificate for the expected hostname. That means that any `https:` or `wss:` connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.\n\nThe first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.\n\nThis has been a requested feature in EventMachine for many years now; see for example [#275][3], [#378][4], and [#814][5]. In June 2020, em-http-request published an [advisory][7] related to this problem and fixed it by [implementing TLS verification][8] in their own codebase; although EventMachine does not implement certificate verification itself, it provides an extension point for\nthe caller to implement it, called [`ssl_verify_peer`][9]. Based on this implementation, we have incorporated similar functionality into faye-websocket.\n\nAfter implementing verification in v1.1.6, em-http-request has elected to leave the `:verify_peer` option switched off by default. We have decided to _enable_ this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:\n\n- talking to the expected server, and will not break under this change\n- being attacked, and would benefit from being alerted to this fact\n- deliberately talking to a server that would be rejected by verification\n\nThe latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be \"working by accident\", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.\n\nWe are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:\n\n```rb\nclient = Faye::Client.new(\u0027https://example.com/\u0027, tls: { verify_peer: false })\n```\n\nUnfortunately we can\u0027t offer an equivalent of the `:root_cert_file` option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system\u0027s root set.\n\nThe same functionality is now supported in the Node.js version, with a `tls` option whose values will be passed to the `https` and `tls` modules as appropriate when making connections. For example, you can provide your own CA certificate:\n\n```js\nvar client = new faye.Client(\u0027https://example.com/\u0027, {\n  tls: {\n    ca: fs.readFileSync(\u0027path/to/certificate.pem\u0027)\n  }\n});\n```\n\nFor further background information on this issue, please see [faye#524][12] and [faye-websocket#129][13]. We would like to thank [Tero Marttila][14] and [Daniel Morsing][15] for providing invaluable assistance and feedback on this issue.\n\n[1]: https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:start_tls\n[2]: https://rubygems.org/gems/eventmachine\n[3]: https://github.com/eventmachine/eventmachine/issues/275\n[4]: https://github.com/eventmachine/eventmachine/pull/378\n[5]: https://github.com/eventmachine/eventmachine/issues/814\n[6]: https://rubygems.org/gems/em-http-request\n[7]: https://securitylab.github.com/advisories/GHSL-2020-094-igrigorik-em-http-request\n[8]: https://github.com/igrigorik/em-http-request/pull/340\n[9]: https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:ssl_verify_peer\n[10]: https://rubygems.org/gems/faye-websocket\n[11]: https://faye.jcoglan.com/\n[12]: https://github.com/faye/faye/issues/524\n[13]: https://github.com/faye/faye-websocket-ruby/pull/129\n[14]: https://github.com/SpComb\n[15]: https://github.com/DanielMorsing",
  "id": "GHSA-3q49-h8f9-9fr9",
  "modified": "2023-05-16T16:03:45Z",
  "published": "2020-07-31T17:39:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15134"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eventmachine/eventmachine/issues/275"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eventmachine/eventmachine/issues/814"
    },
    {
      "type": "WEB",
      "url": "https://github.com/faye/faye/issues/524"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eventmachine/eventmachine/pull/378"
    },
    {
      "type": "WEB",
      "url": "https://github.com/faye/faye-websocket-ruby/pull/129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/igrigorik/em-http-request/pull/340"
    },
    {
      "type": "WEB",
      "url": "https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/faye/faye"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/faye/CVE-2020-15134.yml"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2020-094-igrigorik-em-http-request"
    },
    {
      "type": "WEB",
      "url": "https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:ssl_verify_peer"
    },
    {
      "type": "WEB",
      "url": "https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:start_tls"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing TLS certificate verification"
}

GHSA-3QF7-9XHJ-QCFJ

Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2023-10-26 22:15
VLAI
Summary
Jenkins Koji Plugin globally and unconditionally disables SSL/TLS certificate validation
Details

Jenkins Koji Plugin unconditionally disables SSL/TLS certificate validation for the entire Jenkins controller JVM.

As of publication of this advisory, there is no fix.

Severity
6.5 (Medium)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:koji"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10314"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-26T22:15:15Z",
    "nvd_published_at": "2019-04-30T13:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins Koji Plugin unconditionally disables SSL/TLS certificate validation for the entire Jenkins controller JVM.\n\nAs of publication of this advisory, there is no fix.",
  "id": "GHSA-3qf7-9xhj-qcfj",
  "modified": "2023-10-26T22:15:15Z",
  "published": "2022-05-24T16:44:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10314"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-04-30/#SECURITY-936"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200227073756/http://www.securityfocus.com/bid/108159"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/04/30/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Koji Plugin globally and unconditionally disables SSL/TLS certificate validation"
}

GHSA-3QH5-QQJ2-C78F

Vulnerability from github – Published: 2023-06-30 20:31 – Updated: 2023-06-30 20:31
VLAI
Summary
Keycloak vulnerable to Improper Client Certificate Validation for OAuth/OpenID clients
Details

When a Keycloak server is configured to support mTLS authentication for OAuth/OpenID clients, it does not properly verify the client certificate chain. A client that possesses a proper certificate can authorize itself as any other client and therefore access data that belongs to other clients.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "21.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-2422"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-30T20:31:37Z",
    "nvd_published_at": "2023-10-04T11:15:10Z",
    "severity": "HIGH"
  },
  "details": "When a Keycloak server is configured to support mTLS authentication for OAuth/OpenID clients, it does not properly verify the client certificate chain. A client that possesses a proper certificate can authorize itself as any other client and therefore access data that belongs to other clients.",
  "id": "GHSA-3qh5-qqj2-c78f",
  "modified": "2023-06-30T20:31:37Z",
  "published": "2023-06-30T20:31:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-3qh5-qqj2-c78f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2422"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/5c6c55945a384bfd82e51283096204dcb6f63d91"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:3883"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:3884"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:3885"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:3888"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:3892"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-2422"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2191668"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Keycloak vulnerable to Improper Client Certificate Validation for OAuth/OpenID clients"
}

GHSA-3R3F-MM7W-FQHR

Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-05-13 01:48
VLAI
Details

An issue was discovered in VirusTotal. A maliciously crafted Universal/fat binary can evade third-party code signing checks. By not completing full inspection of the Universal/fat binary, the user of the third-party tool will believe that the code is signed by Apple, but the malicious unsigned code will execute.

Severity
7.8 (High)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-10408"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-13T22:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in VirusTotal. A maliciously crafted Universal/fat binary can evade third-party code signing checks. By not completing full inspection of the Universal/fat binary, the user of the third-party tool will believe that the code is signed by Apple, but the malicious unsigned code will execute.",
  "id": "GHSA-3r3f-mm7w-fqhr",
  "modified": "2022-05-13T01:48:47Z",
  "published": "2022-05-13T01:48:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10408"
    },
    {
      "type": "WEB",
      "url": "https://www.okta.com/security-blog/2018/06/issues-around-third-party-apple-code-signing-checks"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3R3X-M8V7-GPP4

Vulnerability from github – Published: 2025-07-10 18:31 – Updated: 2025-07-10 18:31
VLAI
Details

Improper certificate validation in Zoom Workplace for Linux before version 6.4.13 may allow an unauthorized user to conduct an information disclosure via network access.

Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-46788"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-10T16:15:24Z",
    "severity": "HIGH"
  },
  "details": "Improper certificate validation in Zoom Workplace for Linux before version 6.4.13 may allow an unauthorized user to conduct an information disclosure via network access.",
  "id": "GHSA-3r3x-m8v7-gpp4",
  "modified": "2025-07-10T18:31:26Z",
  "published": "2025-07-10T18:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46788"
    },
    {
      "type": "WEB",
      "url": "https://https://www.zoom.com/en/trust/security-bulletin/zsb-25023"
    }
  ],
  "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-3RQQ-7767-6JQ7

Vulnerability from github – Published: 2026-08-29 03:31 – Updated: 2026-08-29 03:31
VLAI
Details

Traffic interception vulnerability in BOSH Director vCenter CPI allows attackers positioned between BOSH Director and vCenter to impersonate vCenter REST API and capture administrator credentials via HTTP Basic auth, leading to complete virtualization infrastructure takeover.

An attacker who can intercept traffic between the BOSH Director and vCenter can establish a malicious server impersonating the vCenter REST API. When the BOSH Director makes CPI calls to perform routine cloud infrastructure operations, the attacker captures the vCenter administrator username and password transmitted via HTTP Basic authentication.

The vulnerability stems from insufficient authentication security in the communication protocol between BOSH Director and vCenter. While HTTPS may be used, the lack of proper certificate validation and pinning allows attackers to successfully impersonate vCenter endpoints. Because vCenter credentials typically grant full administrative control over the entire virtualization estate, successful credential capture yields complete takeover of every VM, datastore, and network the CPI manages.

This exposure exists on every CPI call (including routine deployment operations, not just when tags are configured) and cannot be mitigated by supplying a CA certificate alone. The attack impacts all infrastructure managed by the compromised vCenter instance, potentially affecting hundreds or thousands of VMs across multiple deployments and environments.

Severity
7.7 (High)
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-41012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-29T03:17:06Z",
    "severity": "HIGH"
  },
  "details": "Traffic interception vulnerability in BOSH Director vCenter CPI allows attackers positioned between BOSH Director and vCenter to impersonate vCenter REST API and capture administrator credentials via HTTP Basic auth, leading to complete virtualization infrastructure takeover.\n\n\n\nAn attacker who can intercept traffic between the BOSH Director and vCenter can establish a malicious server impersonating the vCenter REST API. When the BOSH Director makes CPI calls to perform routine cloud infrastructure operations, the attacker captures the vCenter administrator username and password transmitted via HTTP Basic authentication.\n\n\n\nThe vulnerability stems from insufficient authentication security in the communication protocol between BOSH Director and vCenter. While HTTPS may be used, the lack of proper certificate validation and pinning allows attackers to successfully impersonate vCenter endpoints. Because vCenter credentials typically grant full administrative control over the entire virtualization estate, successful credential capture yields complete takeover of every VM, datastore, and network the CPI manages.\n\n\n\nThis exposure exists on every CPI call (including routine deployment operations, not just when tags are configured) and cannot be mitigated by supplying a CA certificate alone. The attack impacts all infrastructure managed by the compromised vCenter instance, potentially affecting hundreds or thousands of VMs across multiple deployments and environments.",
  "id": "GHSA-3rqq-7767-6jq7",
  "modified": "2026-08-29T03:31:03Z",
  "published": "2026-08-29T03:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41012"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudfoundry.org/blog/cve-2026-41012-bosh-vsphere-cpi-improper-cert-validation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3VQ3-MVHH-HJCP

Vulnerability from github – Published: 2022-06-16 00:00 – Updated: 2022-06-25 00:01
VLAI
Details

Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-32153"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-15T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.",
  "id": "GHSA-3vq3-mvhh-hjcp",
  "modified": "2022-06-25T00:01:03Z",
  "published": "2022-06-16T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32153"
    },
    {
      "type": "WEB",
      "url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation"
    },
    {
      "type": "WEB",
      "url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/network/splunk_identified_ssl_tls_certificates"
    },
    {
      "type": "WEB",
      "url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0603.html"
    }
  ],
  "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-3VWM-FC87-MQ6H

Vulnerability from github – Published: 2022-11-16 12:00 – Updated: 2023-10-30 21:12
VLAI
Summary
Jenkins NS-ND Integration Performance Publisher Plugin disables SSL/TLS certificate validation globally and unconditionally
Details

Jenkins NS-ND Integration Performance Publisher Plugin 4.8.0.143 and earlier globally and unconditionally disables SSL/TLS certificate and hostname validation for the entire Jenkins controller JVM.

NS-ND Integration Performance Publisher Plugin 4.8.0.146 no longer disables SSL/TLS certificate and hostname validation globally.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.jenkins.plugins:cavisson-ns-nd-integration"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.8.0.146"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-45391"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-21T22:23:33Z",
    "nvd_published_at": "2022-11-15T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins NS-ND Integration Performance Publisher Plugin 4.8.0.143 and earlier globally and unconditionally disables SSL/TLS certificate and hostname validation for the entire Jenkins controller JVM.\n\nNS-ND Integration Performance Publisher Plugin 4.8.0.146 no longer disables SSL/TLS certificate and hostname validation globally.",
  "id": "GHSA-3vwm-fc87-mq6h",
  "modified": "2023-10-30T21:12:33Z",
  "published": "2022-11-16T12:00:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45391"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/cavisson-ns-nd-integration-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-11-15/#SECURITY-2910%20%281%29"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-11-15/#SECURITY-2910%20(1)"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/11/15/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins NS-ND Integration Performance Publisher Plugin disables SSL/TLS certificate validation globally and unconditionally"
}

GHSA-3VXP-Q565-46FP

Vulnerability from github – Published: 2022-05-17 02:45 – Updated: 2025-04-20 03:37
VLAI
Details

The TradeKing Forex for iPhone app 1.2.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.

Severity
5.9 (Medium)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-5913"
  ],
  "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 TradeKing Forex for iPhone app 1.2.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-3vxp-q565-46fp",
  "modified": "2025-04-20T03:37:14Z",
  "published": "2022-05-17T02:45:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5913"
    },
    {
      "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-3W65-74C3-P8JP

Vulnerability from github – Published: 2022-05-14 03:07 – Updated: 2022-05-14 03:07
VLAI
Details

Burp Suite Community Edition 1.7.32 and 1.7.33 fail to validate the server certificate in a couple of HTTPS requests which allows a man in the middle to modify or view traffic.

Severity
7.4 (High)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-1153"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-18T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "Burp Suite Community Edition 1.7.32 and 1.7.33 fail to validate the server certificate in a couple of HTTPS requests which allows a man in the middle to modify or view traffic.",
  "id": "GHSA-3w65-74c3-p8jp",
  "modified": "2022-05-14T03:07:22Z",
  "published": "2022-05-14T03:07:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1153"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2018-18"
    },
    {
      "type": "WEB",
      "url": "http://releases.portswigger.net/2018/06/1734.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: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.

← Back to the CWE list