CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
1908 vulnerabilities reference this CWE, most recent first.
GHSA-3P3G-V9C5-JWVW
Vulnerability from github – Published: 2023-02-16 21:30 – Updated: 2023-02-25 00:30An improper certificate validation vulnerability [CWE-295] in FortiOS 7.2.0 through 7.2.3, 7.0.0 through 7.0.7, 6.4 all versions, 6.2 all versions, 6.0 all versions and FortiProxy 7.0.0 through 7.0.6, 2.0 all versions, 1.2 all versions may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the FortiOS/FortiProxy device and remote servers hosting threat feeds (when the latter are configured as Fabric connectors in FortiOS/FortiProxy)
{
"affected": [],
"aliases": [
"CVE-2022-39948"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-16T19:15:00Z",
"severity": "HIGH"
},
"details": "An improper certificate validation vulnerability [CWE-295] in FortiOS 7.2.0 through 7.2.3, 7.0.0 through 7.0.7, 6.4 all versions, 6.2 all versions, 6.0 all versions and FortiProxy 7.0.0 through 7.0.6, 2.0 all versions, 1.2 all versions may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the FortiOS/FortiProxy device and remote servers hosting threat feeds (when the latter are configured as Fabric connectors in FortiOS/FortiProxy)",
"id": "GHSA-3p3g-v9c5-jwvw",
"modified": "2023-02-25T00:30:46Z",
"published": "2023-02-16T21:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39948"
},
{
"type": "WEB",
"url": "https://fortiguard.com/psirt/FG-IR-22-257"
}
],
"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-3P6W-GV5G-XJW9
Vulnerability from github – Published: 2025-10-13 18:31 – Updated: 2025-10-13 20:38When tlsInsecure=False appears in a connection string, certificate validation is disabled.
This vulnerability affects MongoDB Rust Driver versions prior to v3.2.5.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "mongodb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-11695"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-13T20:38:21Z",
"nvd_published_at": "2025-10-13T17:15:34Z",
"severity": "HIGH"
},
"details": "When tlsInsecure=False appears in a connection string, certificate validation is disabled.\n\nThis vulnerability affects MongoDB Rust Driver versions prior to v3.2.5.",
"id": "GHSA-3p6w-gv5g-xjw9",
"modified": "2025-10-13T20:38:21Z",
"published": "2025-10-13T18:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11695"
},
{
"type": "WEB",
"url": "https://github.com/mongodb/mongo-rust-driver/pull/1453"
},
{
"type": "WEB",
"url": "https://github.com/mongodb/mongo-rust-driver/commit/21ed6aeeea386628621b36a6af2a1a248cc87dcf"
},
{
"type": "WEB",
"url": "https://github.com/mongodb/mongo-rust-driver/commit/b918cd6676331c45f26dd1acd13e230aaf17fe6d"
},
{
"type": "PACKAGE",
"url": "https://github.com/mongodb/mongo-rust-driver"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/RUST-2264"
}
],
"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": "MongoDB Rust Driver has certificate validation disabled when `tlsInsecure=False` appears in connection string"
}
GHSA-3P9C-3M43-PW59
Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38Juniper Networks Junos OS on SRX series devices do not verify the HTTPS server certificate before downloading anti-virus updates. This may allow a man-in-the-middle attacker to inject bogus signatures to cause service disruptions or make the device not detect certain types of attacks. Affected Junos OS releases are: 12.1X46 prior to 12.1X46-D71; 12.3X48 prior to 12.3X48-D55; 15.1X49 prior to 15.1X49-D110;
{
"affected": [],
"aliases": [
"CVE-2017-10620"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-13T17:29:00Z",
"severity": "HIGH"
},
"details": "Juniper Networks Junos OS on SRX series devices do not verify the HTTPS server certificate before downloading anti-virus updates. This may allow a man-in-the-middle attacker to inject bogus signatures to cause service disruptions or make the device not detect certain types of attacks. Affected Junos OS releases are: 12.1X46 prior to 12.1X46-D71; 12.3X48 prior to 12.3X48-D55; 15.1X49 prior to 15.1X49-D110;",
"id": "GHSA-3p9c-3m43-pw59",
"modified": "2022-05-13T01:38:20Z",
"published": "2022-05-13T01:38:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10620"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA10822"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3PH8-8G7Q-2432
Vulnerability from github – Published: 2026-05-14 00:31 – Updated: 2026-05-14 00:31SSL verification is disabled in the DNS Cluster system. This could allow for a malicious server to man-in-the-middle the request and capture credentials.
{
"affected": [],
"aliases": [
"CVE-2026-32992"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-13T22:16:43Z",
"severity": "HIGH"
},
"details": "SSL verification is disabled in the DNS Cluster system. This could allow for a malicious server to man-in-the-middle the request and capture credentials.",
"id": "GHSA-3ph8-8g7q-2432",
"modified": "2026-05-14T00:31:56Z",
"published": "2026-05-14T00:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32992"
},
{
"type": "WEB",
"url": "https://support.cpanel.net/hc/en-us/articles/40437241987607-Security-CVE-2026-32992-cPanel-WHM-WP2-Security-Update-May-13-2026"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3PH9-QWH9-55VC
Vulnerability from github – Published: 2022-05-17 01:38 – Updated: 2024-02-14 18:30FilesAnywhere does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.
{
"affected": [],
"aliases": [
"CVE-2012-5819"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-11-04T22:55:00Z",
"severity": "MODERATE"
},
"details": "FilesAnywhere does not verify that the server hostname matches a domain name in the subject\u0027s Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.",
"id": "GHSA-3ph9-qwh9-55vc",
"modified": "2024-02-14T18:30:24Z",
"published": "2022-05-17T01:38:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5819"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/79932"
},
{
"type": "WEB",
"url": "http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3Q49-H8F9-9FR9
Vulnerability from github – Published: 2020-07-31 17:39 – Updated: 2023-05-16 16:03Faye 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.
{
"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:15Jenkins Koji Plugin unconditionally disables SSL/TLS certificate validation for the entire Jenkins controller JVM.
As of publication of this advisory, there is no fix.
{
"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:31When 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.
{
"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:48An 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.
{
"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:31Improper 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.
{
"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"
}
]
}
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.