Total
1102 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-1632 | 2 Fedoraproject, Redhat | 3 Fedora, Ansible Automation Platform, Openshift Container Platform | 2024-11-21 | N/A | 6.5 MEDIUM |
| An Improper Certificate Validation attack was found in Openshift. A re-encrypt Route with destinationCACertificate explicitly set to the default serviceCA skips internal Service TLS certificate validation. This flaw allows an attacker to exploit an invalid certificate, resulting in a loss of confidentiality. | |||||
| CVE-2022-1343 | 2 Netapp, Openssl | 43 A250, A250 Firmware, A700s and 40 more | 2024-11-21 | 4.3 MEDIUM | 5.3 MEDIUM |
| The function `OCSP_basic_verify` verifies the signer certificate on an OCSP response. In the case where the (non-default) flag OCSP_NOCHECKS is used then the response will be positive (meaning a successful verification) even in the case where the response signing certificate fails to verify. It is anticipated that most users of `OCSP_basic_verify` will not use the OCSP_NOCHECKS flag. In this case the `OCSP_basic_verify` function will return a negative value (indicating a fatal error) in the case of a certificate verification failure. The normal expected return value in this case would be 0. This issue also impacts the command line OpenSSL "ocsp" application. When verifying an ocsp response with the "-no_cert_checks" option the command line application will report that the verification is successful even though it has in fact failed. In this case the incorrect successful response will also be accompanied by error messages showing the failure and contradicting the apparently successful result. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). | |||||
| CVE-2022-0759 | 1 Redhat | 1 Kubeclient | 2024-11-21 | 6.8 MEDIUM | 8.1 HIGH |
| A flaw was found in all versions of kubeclient up to (but not including) v4.9.3, the Ruby client for Kubernetes REST API, in the way it parsed kubeconfig files. When the kubeconfig file does not configure custom CA to verify certs, kubeclient ends up accepting any certificate (it wrongly returns VERIFY_NONE). Ruby applications that leverage kubeclient to parse kubeconfig files are susceptible to Man-in-the-middle attacks (MITM). | |||||
| CVE-2022-0123 | 1 Gitlab | 1 Gitlab | 2024-11-21 | 4.9 MEDIUM | 5.9 MEDIUM |
| An issue has been discovered affecting GitLab versions prior to 14.4.5, between 14.5.0 and 14.5.3, and between 14.6.0 and 14.6.1. GitLab does not validate SSL certificates for some of external CI services which makes it possible to perform MitM attacks on connections to these external services. | |||||
| CVE-2021-45490 | 1 3cx | 1 3cx | 2024-11-21 | 6.4 MEDIUM | 9.1 CRITICAL |
| The client applications in 3CX on Windows, the 3CX app for iOS, and the 3CX application for Android through 2022-03-17 lack SSL certificate validation. | |||||
| CVE-2021-45035 | 1 Velneo | 1 Vclient | 2024-11-21 | N/A | 6.3 MEDIUM |
| Velneo vClient on its 28.1.3 version, does not correctly check the certificate of authenticity by default. This could allow an attacker that has access to the network to perform a MITM attack in order to obtain the user´s credentials. | |||||
| CVE-2021-44549 | 1 Apache | 1 Sling Commons Messaging Mail | 2024-11-21 | 5.8 MEDIUM | 7.4 HIGH |
| 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 | |||||
| CVE-2021-44533 | 3 Debian, Nodejs, Oracle | 9 Debian Linux, Node.js, Graalvm and 6 more | 2024-11-21 | 5.0 MEDIUM | 5.3 MEDIUM |
| Node.js < 12.22.9, < 14.18.3, < 16.13.2, and < 17.3.1 did not handle multi-value Relative Distinguished Names correctly. Attackers could craft certificate subjects containing a single-value Relative Distinguished Name that would be interpreted as a multi-value Relative Distinguished Name, for example, in order to inject a Common Name that would allow bypassing the certificate subject verification.Affected versions of Node.js that do not accept multi-value Relative Distinguished Names and are thus not vulnerable to such attacks themselves. However, third-party code that uses node's ambiguous presentation of certificate subjects may be vulnerable. | |||||
| CVE-2021-44532 | 3 Debian, Nodejs, Oracle | 9 Debian Linux, Node.js, Graalvm and 6 more | 2024-11-21 | 5.0 MEDIUM | 5.3 MEDIUM |
| Node.js < 12.22.9, < 14.18.3, < 16.13.2, and < 17.3.1 converts SANs (Subject Alternative Names) to a string format. It uses this string to check peer certificates against hostnames when validating connections. The string format was subject to an injection vulnerability when name constraints were used within a certificate chain, allowing the bypass of these name constraints.Versions of Node.js with the fix for this escape SANs containing the problematic characters in order to prevent the injection. This behavior can be reverted through the --security-revert command-line option. | |||||
| CVE-2021-44531 | 2 Nodejs, Oracle | 8 Node.js, Graalvm, Mysql Cluster and 5 more | 2024-11-21 | 5.8 MEDIUM | 7.4 HIGH |
| Accepting arbitrary Subject Alternative Name (SAN) types, unless a PKI is specifically defined to use a particular SAN type, can result in bypassing name-constrained intermediates. Node.js < 12.22.9, < 14.18.3, < 16.13.2, and < 17.3.1 was accepting URI SAN types, which PKIs are often not defined to use. Additionally, when a protocol allows URI SANs, Node.js did not match the URI correctly.Versions of Node.js with the fix for this disable the URI SAN type when checking a certificate against a hostname. This behavior can be reverted through the --security-revert command-line option. | |||||
| CVE-2021-44273 | 1 E2bn | 1 E2guardian | 2024-11-21 | 5.8 MEDIUM | 7.4 HIGH |
| e2guardian v5.4.x <= v5.4.3r is affected by missing SSL certificate validation in the SSL MITM engine. In standalone mode (i.e., acting as a proxy or a transparent proxy), with SSL MITM enabled, e2guardian, if built with OpenSSL v1.1.x, did not validate hostnames in certificates of the web servers that it connected to, and thus was itself vulnerable to MITM attacks. | |||||
| CVE-2021-43882 | 1 Microsoft | 1 Defender For Iot | 2024-11-21 | 7.5 HIGH | 9.0 CRITICAL |
| Microsoft Defender for IoT Remote Code Execution Vulnerability | |||||
| CVE-2021-43767 | 1 Postgresql | 1 Postgresql | 2024-11-21 | N/A | 5.9 MEDIUM |
| Odyssey passes to client unencrypted bytes from man-in-the-middle When Odyssey storage is configured to use the PostgreSQL server using 'trust' authentication with a 'clientcert' requirement or to use 'cert' authentication, a man-in-the-middle attacker can inject false responses to the client's first few queries. Despite the use of SSL certificate verification and encryption, Odyssey will pass these results to client as if they originated from valid server. This is similar to CVE-2021-23222 for PostgreSQL. | |||||
| CVE-2021-43766 | 1 Odyssey Project | 1 Odyssey | 2024-11-21 | N/A | 8.1 HIGH |
| Odyssey passes to server unencrypted bytes from man-in-the-middle When Odyssey is configured to use certificate Common Name for client authentication, a man-in-the-middle attacker can inject arbitrary SQL queries when a connection is first established, despite the use of SSL certificate verification and encryption. This is similar to CVE-2021-23214 for PostgreSQL. | |||||
| CVE-2021-42027 | 1 Siemens | 1 Sinumerik Edge | 2024-11-21 | 5.8 MEDIUM | 7.4 HIGH |
| A vulnerability has been identified in SINUMERIK Edge (All versions < V3.2). The affected software does not properly validate the server certificate when initiating a TLS connection. This could allow an attacker to spoof a trusted entity by interfering in the communication path between the client and the intended server. | |||||
| CVE-2021-41611 | 2 Fedoraproject, Squid-cache | 2 Fedora, Squid | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| An issue was discovered in Squid 5.0.6 through 5.1.x before 5.2. When validating an origin server or peer certificate, Squid may incorrectly classify certain certificates as trusted. This problem allows a remote server to obtain security trust well improperly. This indication of trust may be passed along to clients, allowing access to unsafe or hijacked services. | |||||
| CVE-2021-41028 | 1 Fortinet | 2 Forticlient, Forticlient Endpoint Management Server | 2024-11-21 | 5.4 MEDIUM | 8.2 HIGH |
| A combination of a use of hard-coded cryptographic key vulnerability [CWE-321] in FortiClientEMS 7.0.1 and below, 6.4.6 and below and an improper certificate validation vulnerability [CWE-297] in FortiClientWindows, FortiClientLinux and FortiClientMac 7.0.1 and below, 6.4.6 and below may allow an unauthenticated and network adjacent attacker to perform a man-in-the-middle attack between the EMS and the FCT via the telemetry protocol. | |||||
| CVE-2021-41019 | 1 Fortinet | 1 Fortios | 2024-11-21 | 4.3 MEDIUM | 3.5 LOW |
| An improper validation of certificate with host mismatch [CWE-297] vulnerability in FortiOS versions 6.4.6 and below may allow the connection to a malicious LDAP server via options in GUI, leading to disclosure of sensitive information, such as AD credentials. | |||||
| CVE-2021-40855 | 1 Europa | 1 Technical Specifications For Digital Covid Certificates | 2024-11-21 | 7.5 HIGH | 9.8 CRITICAL |
| The EU Technical Specifications for Digital COVID Certificates before 1.1 mishandle certificate governance. A non-production public key certificate could have been used in production. | |||||
| CVE-2021-40831 | 2 Amazon, Apple | 3 Amazon Web Services Aws-c-io, Amazon Web Services Internet Of Things Device Software Development Kit V2, Macos | 2024-11-21 | 6.0 MEDIUM | 6.3 MEDIUM |
| The AWS IoT Device SDK v2 for Java, Python, C++ and Node.js appends a user supplied Certificate Authority (CA) to the root CAs instead of overriding it on macOS systems. Additionally, SNI validation is also not enabled when the CA has been “overridden”. TLS handshakes will thus succeed if the peer can be verified either from the user-supplied CA or the system’s default trust-store. Attackers with access to a host’s trust stores or are able to compromise a certificate authority already in the host's trust store (note: the attacker must also be able to spoof DNS in this case) may be able to use this issue to bypass CA pinning. An attacker could then spoof the MQTT broker, and either drop traffic and/or respond with the attacker's data, but they would not be able to forward this data on to the MQTT broker because the attacker would still need the user's private keys to authenticate against the MQTT broker. The 'aws_tls_ctx_options_override_default_trust_store_*' function within the aws-c-io submodule has been updated to address this behavior. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.7.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.14.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.6.0 on macOS. Amazon Web Services AWS-C-IO 0.10.7 on macOS. | |||||