Total
1005 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-29482 | 1 Dena | 1 Mobaoku-auction \& Flea Market | 2024-02-28 | 4.3 MEDIUM | 3.7 LOW |
| 'Mobaoku-Auction&Flea Market' App for iOS versions prior to 5.5.16 improperly verifies server certificates, which may allow an attacker to eavesdrop on an encrypted communication via a man-in-the-middle attack. | |||||
| CVE-2022-22885 | 1 Hutool | 1 Hutool | 2024-02-28 | 7.5 HIGH | 9.8 CRITICAL |
| Hutool v5.7.18's HttpRequest was discovered to ignore all TLS/SSL certificate validation. | |||||
| CVE-2021-44533 | 3 Debian, Nodejs, Oracle | 9 Debian Linux, Node.js, Graalvm and 6 more | 2024-02-28 | 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-2022-32156 | 1 Splunk | 2 Splunk, Universal Forwarder | 2024-02-28 | 6.8 MEDIUM | 8.1 HIGH |
| In Splunk Enterprise and Universal Forwarder versions before 9.0, the Splunk command-line interface (CLI) did not validate TLS certificates while connecting to a remote Splunk platform instance by default. After updating to version 9.0, see Configure TLS host name validation for the Splunk CLI https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI to enable the remediation. The vulnerability does not affect the Splunk Cloud Platform. At the time of publishing, we have no evidence of exploitation of this vulnerability by external parties. The issue requires conditions beyond the control of a potential bad actor such as a machine-in-the-middle attack. Hence, Splunk rates the complexity of the attack as High. | |||||
| CVE-2021-27768 | 1 Hcltech | 1 Verse | 2024-02-28 | 4.3 MEDIUM | 5.9 MEDIUM |
| Using the ability to perform a Man-in-the-Middle (MITM) attack, which indicates a lack of hostname verification, sensitive account information was able to be intercepted. In this specific scenario, the application's network traffic was intercepted using a proxy server set up in 'transparent' mode while a certificate with an invalid hostname was active. The Android application was found to have hostname verification issues during the server setup and login flows; however, the application did not process requests post-login. | |||||
| CVE-2022-21657 | 1 Envoyproxy | 1 Envoy | 2024-02-28 | 4.0 MEDIUM | 6.5 MEDIUM |
| Envoy is an open source edge and service proxy, designed for cloud-native applications. In affected versions Envoy does not restrict the set of certificates it accepts from the peer, either as a TLS client or a TLS server, to only those certificates that contain the necessary extendedKeyUsage (id-kp-serverAuth and id-kp-clientAuth, respectively). This means that a peer may present an e-mail certificate (e.g. id-kp-emailProtection), either as a leaf certificate or as a CA in the chain, and it will be accepted for TLS. This is particularly bad when combined with the issue described in pull request #630, in that it allows a Web PKI CA that is intended only for use with S/MIME, and thus exempted from audit or supervision, to issue TLS certificates that will be accepted by Envoy. As a result Envoy will trust upstream certificates that should not be trusted. There are no known workarounds to this issue. Users are advised to upgrade. | |||||
| CVE-2022-24968 | 1 Mellium | 1 Xmpp | 2024-02-28 | 4.3 MEDIUM | 5.9 MEDIUM |
| In Mellium mellium.im/xmpp through 0.21.0, an attacker capable of spoofing DNS TXT records can redirect a WebSocket connection request to a server under their control without causing TLS certificate verification to fail. This occurs because the wrong host name is selected during this verification. | |||||
| CVE-2022-26766 | 1 Apple | 6 Ipados, Iphone Os, Mac Os X and 3 more | 2024-02-28 | 4.3 MEDIUM | 5.5 MEDIUM |
| A certificate parsing issue was addressed with improved checks. This issue is fixed in tvOS 15.5, iOS 15.5 and iPadOS 15.5, Security Update 2022-004 Catalina, watchOS 8.6, macOS Big Sur 11.6.6, macOS Monterey 12.4. A malicious app may be able to bypass signature validation. | |||||
| CVE-2021-44531 | 2 Nodejs, Oracle | 8 Node.js, Graalvm, Mysql Cluster and 5 more | 2024-02-28 | 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-2022-26493 | 1 Drupal | 1 Saml Sp 2.0 Single Sign On | 2024-02-28 | 6.5 MEDIUM | 8.8 HIGH |
| Xecurify's miniOrange Premium, Standard, and Enterprise Drupal SAML SP modules possess an authentication and authorization bypass vulnerability. An attacker with access to a HTTP-request intercepting method is able to bypass authentication and authorization by removing the SAML Assertion Signature - impersonating existing users and existing roles, including administrative users/roles. This vulnerability is not mitigated by configuring the module to enforce signatures or certificate checks. Xecurify recommends updating miniOrange modules to their most recent versions. This vulnerability is present in paid versions of the miniOrange Drupal SAML SP product affecting Drupal 7, 8, and 9. | |||||
| CVE-2013-10001 | 1 Htc | 5 Mail, One Sv, One X and 2 more | 2024-02-28 | 4.3 MEDIUM | 5.9 MEDIUM |
| A vulnerability was found in HTC One/Sense 4.x. It has been rated as problematic. Affected by this issue is the certification validation of the mail client. An exploit has been disclosed to the public and may be used. | |||||
| CVE-2022-20034 | 2 Google, Mediatek | 22 Android, Mt6580, Mt6735 and 19 more | 2024-02-28 | 4.6 MEDIUM | 6.8 MEDIUM |
| In Preloader XFLASH, there is a possible escalation of privilege due to an improper certificate validation. This could lead to local escalation of privilege for an attacker who has physical access to the device with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS06160806; Issue ID: ALPS06160806. | |||||
| CVE-2020-26184 | 2 Dell, Oracle | 4 Bsafe Micro-edition-suite, Http Server, Security Service and 1 more | 2024-02-28 | 5.0 MEDIUM | 7.5 HIGH |
| Dell BSAFE Micro Edition Suite, versions prior to 4.5.1, contain an Improper Certificate Validation vulnerability. | |||||
| CVE-2021-3618 | 5 Debian, F5, Fedoraproject and 2 more | 5 Debian Linux, Nginx, Fedora and 2 more | 2024-02-28 | 5.8 MEDIUM | 7.4 HIGH |
| ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using compatible certificates, such as multi-domain or wildcard certificates. A MiTM attacker having access to victim's traffic at the TCP/IP layer can redirect traffic from one subdomain to another, resulting in a valid TLS session. This breaks the authentication of TLS and cross-protocol attacks may be possible where the behavior of one protocol service may compromise the other at the application layer. | |||||
| CVE-2022-20081 | 2 Google, Mediatek | 27 Android, Mt6580, Mt6735 and 24 more | 2024-02-28 | 4.3 MEDIUM | 5.9 MEDIUM |
| In A-GPS, there is a possible man in the middle attack due to improper certificate validation. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS06461919; Issue ID: ALPS06461919. | |||||
| CVE-2021-29726 | 1 Ibm | 2 Secure External Authentication Server, Sterling Secure Proxy | 2024-02-28 | 5.0 MEDIUM | 5.3 MEDIUM |
| IBM Sterling Secure Proxy 6.0.3 and IBM Secure External Authentication Server 6.0.3 does not properly ensure that a certificate is actually associated with the host due to improper validation of certificates. IBM X-Force ID: 201104. | |||||
| CVE-2021-3698 | 2 Cockpit-project, Redhat | 2 Cockpit, Enterprise Linux | 2024-02-28 | 5.0 MEDIUM | 7.5 HIGH |
| A flaw was found in Cockpit in versions prior to 260 in the way it handles the certificate verification performed by the System Security Services Daemon (SSSD). This flaw allows client certificates to authenticate successfully, regardless of the Certificate Revocation List (CRL) configuration or the certificate status. The highest threat from this vulnerability is to confidentiality. | |||||
| CVE-2022-32152 | 1 Splunk | 2 Splunk, Splunk Cloud Platform | 2024-02-28 | 6.5 MEDIUM | 7.2 HIGH |
| 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. | |||||
| CVE-2022-1343 | 2 Netapp, Openssl | 43 A250, A250 Firmware, A700s and 40 more | 2024-02-28 | 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-2021-29656 | 1 Pexip | 1 Infinity Connect | 2024-02-28 | 7.5 HIGH | 9.8 CRITICAL |
| Pexip Infinity Connect before 1.8.0 mishandles TLS certificate validation. The allow list is not properly checked. | |||||