CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
1917 vulnerabilities reference this CWE, most recent first.
GHSA-C46X-8Q9C-R3VX
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2025-07-23 15:31A vulnerability in the Cisco Identity Services Engine (ISE) integration feature of the Cisco DNA Center Software could allow an unauthenticated, remote attacker to gain unauthorized access to sensitive data. The vulnerability is due to an incomplete validation of the X.509 certificate used when establishing a connection between DNA Center and an ISE server. An attacker could exploit this vulnerability by supplying a crafted certificate and could then intercept communications between the ISE and DNA Center. A successful exploit could allow the attacker to view and alter sensitive information that the ISE maintains about clients that are connected to the network.
{
"affected": [],
"aliases": [
"CVE-2021-1134"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-29T03:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the Cisco Identity Services Engine (ISE) integration feature of the Cisco DNA Center Software could allow an unauthenticated, remote attacker to gain unauthorized access to sensitive data. The vulnerability is due to an incomplete validation of the X.509 certificate used when establishing a connection between DNA Center and an ISE server. An attacker could exploit this vulnerability by supplying a crafted certificate and could then intercept communications between the ISE and DNA Center. A successful exploit could allow the attacker to view and alter sensitive information that the ISE maintains about clients that are connected to the network.",
"id": "GHSA-c46x-8q9c-r3vx",
"modified": "2025-07-23T15:31:07Z",
"published": "2022-05-24T19:06:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1134"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-dnac-certvalid-USEj2CZk"
}
],
"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-C4FC-CX58-4V39
Vulnerability from github – Published: 2022-05-14 01:02 – Updated: 2022-05-14 01:02Sennheiser HeadSetup 7.3.4903 places Certification Authority (CA) certificates into the Trusted Root CA store of the local system, and publishes the private key in the SennComCCKey.pem file within the public software distribution, which allows remote attackers to spoof arbitrary web sites or software publishers for several years, even if the HeadSetup product is uninstalled. NOTE: a vulnerability-assessment approach must check all Windows systems for CA certificates with a CN of 127.0.0.1 or SennComRootCA, and determine whether those certificates are unwanted.
{
"affected": [],
"aliases": [
"CVE-2018-17612"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-09T21:29:00Z",
"severity": "HIGH"
},
"details": "Sennheiser HeadSetup 7.3.4903 places Certification Authority (CA) certificates into the Trusted Root CA store of the local system, and publishes the private key in the SennComCCKey.pem file within the public software distribution, which allows remote attackers to spoof arbitrary web sites or software publishers for several years, even if the HeadSetup product is uninstalled. NOTE: a vulnerability-assessment approach must check all Windows systems for CA certificates with a CN of 127.0.0.1 or SennComRootCA, and determine whether those certificates are unwanted.",
"id": "GHSA-c4fc-cx58-4v39",
"modified": "2022-05-14T01:02:20Z",
"published": "2022-05-14T01:02:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17612"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180029"
},
{
"type": "WEB",
"url": "https://www.secorvo.de/publikationen/headsetup-vulnerability-report-secorvo-2018.pdf"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106045"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C4RH-4376-GFF4
Vulnerability from github – Published: 2021-11-24 21:12 – 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 Unix systems. 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 override the default trust store. This corrects this issue. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.6.1 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.12.7 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.5.3 on Linux/Unix. Amazon Web Services AWS-C-IO 0.10.4 on Linux/Unix.
{
"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.5.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "awsiotsdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-40830"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-24T20:28:03Z",
"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 Unix systems. 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 \u0027aws_tls_ctx_options_override_default_trust_store_*\u0027 function within the aws-c-io submodule has been updated to override the default trust store. This corrects this issue. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.6.1 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.12.7 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.5.3 on Linux/Unix. Amazon Web Services AWS-C-IO 0.10.4 on Linux/Unix.",
"id": "GHSA-c4rh-4376-gff4",
"modified": "2024-11-18T16:26:17Z",
"published": "2021-11-24T21:12:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40830"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-java-v2/commit/67950ad2a02f2f9355c310b69dc9226b017f32f2"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-js-v2/commit/53a36e3ac203291494120604d416b6de59177cac"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-iot-device-sdk-python-v2/commit/0450ce68add7e3d05c6d781ecdac953c299c053a"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-c4rh-4376-gff4"
},
{
"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-863.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-C597-F74M-JGC2
Vulnerability from github – Published: 2022-02-09 00:56 – Updated: 2021-04-01 21:57A flaw was found in Keycloak in versions before 10.0.0, where it does not perform the TLS hostname verification while sending emails using the SMTP server. This flaw allows an attacker to perform a man-in-the-middle (MITM) attack.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-parent"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-1758"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-297"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-01T21:57:32Z",
"nvd_published_at": "2020-05-15T19:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Keycloak in versions before 10.0.0, where it does not perform the TLS hostname verification while sending emails using the SMTP server. This flaw allows an attacker to perform a man-in-the-middle (MITM) attack.",
"id": "GHSA-c597-f74m-jgc2",
"modified": "2021-04-01T21:57:32Z",
"published": "2022-02-09T00:56:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1758"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-1758"
},
{
"type": "WEB",
"url": "https://issues.redhat.com/browse/KEYCLOAK-13285"
}
],
"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": "Improper Certificate Validation and Improper Validation of Certificate with Host Mismatch in Keycloak"
}
GHSA-C5CJ-HMH6-45PV
Vulnerability from github – Published: 2025-02-20 06:31 – Updated: 2025-03-11 15:30IBM OpenPages with Watson 8.3 and 9.0
could allow a remote attacker to spoof mail server identity when using SSL/TLS security. An attacker could exploit this vulnerability to gain access to sensitive information disclosed through email notifications generated by OpenPages or disrupt notification delivery.
{
"affected": [],
"aliases": [
"CVE-2024-49782"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-297"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-20T04:15:10Z",
"severity": "MODERATE"
},
"details": "IBM OpenPages with Watson 8.3 and 9.0\u00a0\n\n\n\ncould allow a remote attacker to spoof mail server identity when using SSL/TLS security. An attacker could exploit this vulnerability to gain access to sensitive information disclosed through email notifications generated by OpenPages or disrupt notification delivery.",
"id": "GHSA-c5cj-hmh6-45pv",
"modified": "2025-03-11T15:30:57Z",
"published": "2025-02-20T06:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49782"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7183541"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C5FP-X2H5-VJV7
Vulnerability from github – Published: 2022-09-25 00:00 – Updated: 2022-09-30 00:00Delayed TLS hostname verification in the Pulsar Java Client and the Pulsar Proxy make each client vulnerable to a man in the middle attack. Connections from the Pulsar Java Client to the Pulsar Broker/Proxy and connections from the Pulsar Proxy to the Pulsar Broker are vulnerable. Authentication data is sent before verifying the server’s TLS certificate matches the hostname, which means authentication data could be exposed to an attacker. 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 by providing the client with a cryptographically valid certificate for an unrelated host. Because the client sends authentication data before performing hostname verification, an attacker could gain access to the client’s authentication data. The client eventually closes the connection when it verifies the hostname and identifies the targeted hostname does not match a hostname on the certificate. Because the client eventually closes the connection, the value of the intercepted authentication data depends on the authentication method used by the client. Token based authentication and username/password authentication methods are vulnerable because the authentication data can be used to impersonate the client in a separate session. This issue affects Apache Pulsar Java Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; 2.6.4 and earlier.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-client"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.8.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pulsar:pulsar-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.10.0"
},
{
"fixed": "2.10.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.10.0"
]
}
],
"aliases": [
"CVE-2022-33681"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T00:00:47Z",
"nvd_published_at": "2022-09-23T10:15:00Z",
"severity": "MODERATE"
},
"details": "Delayed TLS hostname verification in the Pulsar Java Client and the Pulsar Proxy make each client vulnerable to a man in the middle attack. Connections from the Pulsar Java Client to the Pulsar Broker/Proxy and connections from the Pulsar Proxy to the Pulsar Broker are vulnerable. Authentication data is sent before verifying the server\u2019s TLS certificate matches the hostname, which means authentication data could be exposed to an attacker. 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 by providing the client with a cryptographically valid certificate for an unrelated host. Because the client sends authentication data before performing hostname verification, an attacker could gain access to the client\u2019s authentication data. The client eventually closes the connection when it verifies the hostname and identifies the targeted hostname does not match a hostname on the certificate. Because the client eventually closes the connection, the value of the intercepted authentication data depends on the authentication method used by the client. Token based authentication and username/password authentication methods are vulnerable because the authentication data can be used to impersonate the client in a separate session. This issue affects Apache Pulsar Java Client 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-c5fp-x2h5-vjv7",
"modified": "2022-09-30T00:00:47Z",
"published": "2022-09-25T00:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33681"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/pulsar/tree/db26073728bf86fc80deecaece2dc02b50bbb9b5/pulsar-client"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/fpo6x10trvn20hlk0dmnr5vlz5v4kl3d"
}
],
"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 Java Client vulnerable to Improper Certificate Validation"
}
GHSA-C5WM-WJMG-6V8P
Vulnerability from github – Published: 2022-07-07 00:00 – Updated: 2022-07-15 00:00A insecure configuration for certificate verification (http.verify_mode = OpenSSL::SSL::VERIFY_NONE) may lead to verification bypass in Red Hat CloudForms 5.x.
{
"affected": [],
"aliases": [
"CVE-2014-8164"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-06T20:15:00Z",
"severity": "CRITICAL"
},
"details": "A insecure configuration for certificate verification (http.verify_mode = OpenSSL::SSL::VERIFY_NONE) may lead to verification bypass in Red Hat CloudForms 5.x.",
"id": "GHSA-c5wm-wjmg-6v8p",
"modified": "2022-07-15T00:00:23Z",
"published": "2022-07-07T00:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-8164"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1151208"
}
],
"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"
}
]
}
GHSA-C69W-JJ56-834W
Vulnerability from github – Published: 2021-12-16 14:12 – Updated: 2022-01-04 19:09Apache Sling Commons Messaging Mail provides a simple layer on top of JavaMail/Jakarta Mail for OSGi to send mails via SMTPS. To reduce the risk of "man in the middle" attacks additional server identity checks must be performed when accessing mail servers. For compatibility reasons these additional checks are disabled by default in JavaMail/Jakarta Mail. The SimpleMailService in Apache Sling Commons Messaging Mail 1.0 lacks an option to enable these checks for the shared mail session. A user could enable these checks nevertheless by accessing the session via the message created by SimpleMessageBuilder and setting the property mail.smtps.ssl.checkserveridentity to true. Apache Sling Commons Messaging Mail 2.0 adds support for enabling server identity checks and these checks are enabled by default. - https://javaee.github.io/javamail/docs/SSLNOTES.txt - https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html - https://github.com/eclipse-ee4j/mail/issues/429
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.sling:org.apache.sling.commons.messaging.mail"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-44549"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-297"
],
"github_reviewed": true,
"github_reviewed_at": "2021-12-15T15:15:17Z",
"nvd_published_at": "2021-12-14T16:15:00Z",
"severity": "HIGH"
},
"details": "Apache Sling Commons Messaging Mail provides a simple layer on top of JavaMail/Jakarta Mail for OSGi to send mails via SMTPS. To reduce the risk of \"man in the middle\" attacks additional server identity checks must be performed when accessing mail servers. For compatibility reasons these additional checks are disabled by default in JavaMail/Jakarta Mail. The SimpleMailService in Apache Sling Commons Messaging Mail 1.0 lacks an option to enable these checks for the shared mail session. A user could enable these checks nevertheless by accessing the session via the message created by SimpleMessageBuilder and setting the property mail.smtps.ssl.checkserveridentity to true. Apache Sling Commons Messaging Mail 2.0 adds support for enabling server identity checks and these checks are enabled by default. - https://javaee.github.io/javamail/docs/SSLNOTES.txt - https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html - https://github.com/eclipse-ee4j/mail/issues/429",
"id": "GHSA-c69w-jj56-834w",
"modified": "2022-01-04T19:09:34Z",
"published": "2021-12-16T14:12:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44549"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/mail/issues/429"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse-ee4j"
},
{
"type": "WEB",
"url": "https://javaee.github.io/javamail/docs/SSLNOTES.txt"
},
{
"type": "WEB",
"url": "https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/l8p9h2bqvkj6rhv4w8kzctb817415b7f"
}
],
"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"
}
],
"summary": "Improper Certificate Validation and Improper Validation of Certificate with Host Mismatch in Apache Sling Commons Messaging Mail"
}
GHSA-C78C-FX8F-9542
Vulnerability from github – Published: 2022-05-14 01:32 – Updated: 2022-05-14 01:32An issue was discovered in the Bosch Smart Camera App before 1.3.1 for Android. Due to improperly implemented TLS certificate checks, a malicious actor could potentially succeed in executing a man-in-the-middle attack for some connections. (The Bosch Smart Home App is not affected. iOS Apps are not affected.)
{
"affected": [],
"aliases": [
"CVE-2019-7728"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-22T13:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in the Bosch Smart Camera App before 1.3.1 for Android. Due to improperly implemented TLS certificate checks, a malicious actor could potentially succeed in executing a man-in-the-middle attack for some connections. (The Bosch Smart Home App is not affected. iOS Apps are not affected.)",
"id": "GHSA-c78c-fx8f-9542",
"modified": "2022-05-14T01:32:42Z",
"published": "2022-05-14T01:32:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7728"
},
{
"type": "WEB",
"url": "https://psirt.bosch.com/Advisory/BOSCH-2019-0202.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C7CX-RFW4-4W69
Vulnerability from github – Published: 2022-05-14 01:50 – Updated: 2022-05-14 01:50A spoofing vulnerability exists for the Azure IoT Device Provisioning for the C SDK library using the HTTP protocol on Windows platform, aka "Azure IoT SDK Spoofing Vulnerability." This affects C SDK.
{
"affected": [],
"aliases": [
"CVE-2018-8479"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-13T00:29:00Z",
"severity": "MODERATE"
},
"details": "A spoofing vulnerability exists for the Azure IoT Device Provisioning for the C SDK library using the HTTP protocol on Windows platform, aka \"Azure IoT SDK Spoofing Vulnerability.\" This affects C SDK.",
"id": "GHSA-c7cx-rfw4-4w69",
"modified": "2022-05-14T01:50:06Z",
"published": "2022-05-14T01:50:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8479"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8479"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105323"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"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.