CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
2177 vulnerabilities reference this CWE, most recent first.
GHSA-HXC4-7759-8JQ5
Vulnerability from github – Published: 2026-09-24 21:32 – Updated: 2026-09-24 21:32Dell ThinOS 10, versions prior to SecurityAddon_2605.10.2766_T10, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Protection mechanism bypass and Unauthorized access.
{
"affected": [],
"aliases": [
"CVE-2026-82157"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-24T19:17:17Z",
"severity": "HIGH"
},
"details": "Dell ThinOS 10, versions prior to SecurityAddon_2605.10.2766_T10, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Protection mechanism bypass and Unauthorized access.",
"id": "GHSA-hxc4-7759-8jq5",
"modified": "2026-09-24T21:32:48Z",
"published": "2026-09-24T21:32:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82157"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000506503/dsa-2026-404-security-update-for-dell-thinos-10-for-multiple-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
"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-HXQ8-HCGP-QP7J
Vulnerability from github – Published: 2026-09-03 18:31 – Updated: 2026-09-03 18:31In the current development version of Eclipse aeriOS, for which no official release has yet been published, the Federator component disables TLS certificate validation for outbound HTTPS connections by default. When the TLS_CERTIFICATE_VALIDATION environment variable is unset or set to false, the component configures its HTTP transport to skip TLS certificate verification.
As a result, an attacker able to intercept network communications between the Federator and external services could impersonate those services and intercept sensitive information transmitted over HTTPS, including OAuth client credentials and bearer tokens.
The issue has been addressed by enabling TLS certificate validation by default. The TLS_CERTIFICATE_VALIDATION environment variable is now set to true in the default configuration provided by the Helm chart and Docker Compose deployment.
{
"affected": [],
"aliases": [
"CVE-2026-84736"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-03T17:17:25Z",
"severity": "HIGH"
},
"details": "In the current development version of Eclipse aeriOS, for which no official release has yet been published, the Federator component disables TLS certificate validation for outbound HTTPS connections by default. When the TLS_CERTIFICATE_VALIDATION environment variable is unset or set to false, the component configures its HTTP transport to skip TLS certificate verification.\n\n\n\n\nAs a result, an attacker able to intercept network communications between the Federator and external services could impersonate those services and intercept sensitive information transmitted over HTTPS, including OAuth client credentials and bearer tokens.\n\n\n\n\nThe issue has been addressed by enabling TLS certificate validation by default. The TLS_CERTIFICATE_VALIDATION environment variable is now set to true in the default configuration provided by the Helm chart and Docker Compose deployment.",
"id": "GHSA-hxq8-hcgp-qp7j",
"modified": "2026-09-03T18:31:49Z",
"published": "2026-09-03T18:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84736"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-aerios/federator/commit/9c63b60becc9873b0195ff9cd6582b69cb12d4f2"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/755"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-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-J295-77C3-9FRF
Vulnerability from github – Published: 2026-08-03 03:31 – Updated: 2026-09-02 15:34In Bouncy Castle for Java before 1.85, Stapled OCSP response accepted without binding to the checked certificate. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
{
"affected": [],
"aliases": [
"CVE-2026-58062"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-03T03:16:45Z",
"severity": "CRITICAL"
},
"details": "In Bouncy Castle for Java before 1.85, Stapled OCSP response accepted without binding to the checked certificate. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).",
"id": "GHSA-j295-77c3-9frf",
"modified": "2026-09-02T15:34:23Z",
"published": "2026-08-03T03:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58062"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/add5f822660f3b2c29fd824e2f4095469c42a1c7"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9058062"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE-2026-58062"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber",
"type": "CVSS_V4"
}
]
}
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"
}
]
}
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.