Total
987 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-3913 | 1 Rapid7 | 1 Nexpose | 2023-11-07 | N/A | 5.3 MEDIUM |
| Rapid7 Nexpose and InsightVM versions 6.6.82 through 6.6.177 fail to validate the certificate of the update server when downloading updates. This failure could allow an attacker in a privileged position on the network to provide their own HTTPS endpoint, or intercept communications to the legitimate endpoint. The attacker would need some pre-existing access to at least one node on the network path between the Rapid7-controlled update server and the Nexpose/InsightVM application, and the ability to either spoof the update server's FQDN or redirect legitimate traffic to the attacker's server in order to exploit this vulnerability. Note that even in this scenario, an attacker could not normally replace an update package with a malicious package, since the update process validates a separate, code-signing certificate, distinct from the HTTPS certificate used for communication. This issue was resolved on February 1, 2023 in update 6.6.178 of Nexpose and InsightVM. | |||||
| CVE-2022-39948 | 1 Fortinet | 2 Fortios, Fortiproxy | 2023-11-07 | N/A | 7.4 HIGH |
| 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) | |||||
| CVE-2022-39264 | 2 Fedoraproject, Nheko-reborn | 2 Fedora, Nheko | 2023-11-07 | N/A | 5.9 MEDIUM |
| nheko is a desktop client for the Matrix communication application. All versions below 0.10.2 are vulnerable homeservers inserting malicious secrets, which could lead to man-in-the-middle attacks. Users can upgrade to version 0.10.2 to protect against this issue. As a workaround, one may apply the patch manually, avoid doing verifications of one's own devices, and/or avoid pressing the request button in the settings menu. | |||||
| CVE-2022-34404 | 1 Dell | 1 System Update | 2023-11-07 | N/A | 6.0 MEDIUM |
| Dell System Update, version 2.0.0 and earlier, contains an Improper Certificate Validation in data parser module. A local attacker with high privileges could potentially exploit this vulnerability, leading to credential theft and/or denial of service. | |||||
| CVE-2022-34156 | 1 Hjholdings | 1 Hulu | 2023-11-07 | N/A | 4.8 MEDIUM |
| 'Hulu / フールー' App for iOS versions prior to 3.0.81 improperly verifies server certificates, which may allow an attacker to eavesdrop on an encrypted communication via a man-in-the-middle attack. | |||||
| CVE-2022-32531 | 1 Apache | 1 Bookkeeper | 2023-11-07 | N/A | 5.9 MEDIUM |
| The Apache Bookkeeper Java Client (before 4.14.6 and also 4.15.0) does not close the connection to the bookkeeper server when TLS hostname verification fails. This leaves the bookkeeper client vulnerable to a man in the middle attack. The problem affects BookKeeper client prior to versions 4.14.6 and 4.15.1. | |||||
| CVE-2022-32156 | 1 Splunk | 2 Splunk, Universal Forwarder | 2023-11-07 | 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-2022-22549 | 1 Dell | 1 Emc Powerscale Onefs | 2023-11-07 | 6.8 MEDIUM | 8.1 HIGH |
| Dell PowerScale OneFS, 8.2.x-9.3.x, contains a Improper Certificate Validation. A unauthenticated remote attacker could potentially exploit this vulnerability, leading to a man-in-the-middle capture of administrative credentials. | |||||
| CVE-2022-22305 | 1 Fortinet | 4 Fortianalyzer, Fortimanager, Fortios and 1 more | 2023-11-07 | N/A | 4.2 MEDIUM |
| An improper certificate validation vulnerability [CWE-295] in FortiManager 7.0.1 and below, 6.4.6 and below; FortiAnalyzer 7.0.2 and below, 6.4.7 and below; FortiOS 6.2.x and 6.0.x; FortiSandbox 4.0.x, 3.2.x and 3.1.x may allow a network adjacent and unauthenticated attacker to man-in-the-middle the communication between the listed products and some external peers. | |||||
| CVE-2022-20860 | 1 Cisco | 1 Nexus Dashboard | 2023-11-07 | N/A | 7.4 HIGH |
| A vulnerability in the SSL/TLS implementation of Cisco Nexus Dashboard could allow an unauthenticated, remote attacker to alter communications with associated controllers or view sensitive information. This vulnerability exists because SSL server certificates are not validated when Cisco Nexus Dashboard is establishing a connection to Cisco Application Policy Infrastructure Controller (APIC), Cisco Cloud APIC, or Cisco Nexus Dashboard Fabric Controller, formerly Data Center Network Manager (DCNM) controllers. An attacker could exploit this vulnerability by using man-in-the-middle techniques to intercept the traffic between the affected device and the controllers, and then using a crafted certificate to impersonate the controllers. A successful exploit could allow the attacker to alter communications between devices or view sensitive information, including Administrator credentials for these controllers. | |||||
| CVE-2022-20813 | 1 Cisco | 2 Expressway, Telepresence Video Communication Server | 2023-11-07 | 4.3 MEDIUM | 5.9 MEDIUM |
| Multiple vulnerabilities in the API and in the web-based management interface of Cisco Expressway Series and Cisco TelePresence Video Communication Server (VCS) could allow a remote attacker to overwrite arbitrary files or conduct null byte poisoning attacks on an affected device. Note: Cisco Expressway Series refers to the Expressway Control (Expressway-C) device and the Expressway Edge (Expressway-E) device. For more information about these vulnerabilities, see the Details section of this advisory. | |||||
| CVE-2022-1343 | 2 Netapp, Openssl | 43 A250, A250 Firmware, A700s and 40 more | 2023-11-07 | 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-44549 | 1 Apache | 1 Sling Commons Messaging Mail | 2023-11-07 | 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-43767 | 1 Postgresql | 1 Postgresql | 2023-11-07 | 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 | 2023-11-07 | 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-41611 | 2 Fedoraproject, Squid-cache | 2 Fedora, Squid | 2023-11-07 | 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-3935 | 4 Debian, Fedoraproject, Pgbouncer and 1 more | 4 Debian Linux, Fedora, Pgbouncer and 1 more | 2023-11-07 | 5.1 MEDIUM | 8.1 HIGH |
| When PgBouncer is configured to use "cert" authentication, a man-in-the-middle attacker can inject arbitrary SQL queries when a connection is first established, despite the use of TLS certificate verification and encryption. This flaw affects PgBouncer versions prior to 1.16.1. | |||||
| CVE-2021-3636 | 1 Redhat | 1 Openshift | 2023-11-07 | 4.1 MEDIUM | 4.6 MEDIUM |
| It was found in OpenShift, before version 4.8, that the generated certificate for the in-cluster Service CA, incorrectly included additional certificates. The Service CA is automatically mounted into all pods, allowing them to safely connect to trusted in-cluster services that present certificates signed by the trusted Service CA. The incorrect inclusion of additional CAs in this certificate would allow an attacker that compromises any of the additional CAs to masquerade as a trusted in-cluster service. | |||||
| CVE-2021-3450 | 10 Fedoraproject, Freebsd, Mcafee and 7 more | 35 Fedora, Freebsd, Web Gateway and 32 more | 2023-11-07 | 5.8 MEDIUM | 7.4 HIGH |
| The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1h-1.1.1j). | |||||
| CVE-2021-3406 | 2 Fedoraproject, Keylime | 2 Fedora, Keylime | 2023-11-07 | 7.5 HIGH | 9.8 CRITICAL |
| A flaw was found in keylime 5.8.1 and older. The issue in the Keylime agent and registrar code invalidates the cryptographic chain of trust from the Endorsement Key certificate to agent attestations. | |||||