Total
976 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-37437 | 1 Splunk | 1 Splunk | 2022-08-18 | N/A | 9.8 CRITICAL |
| When using Ingest Actions to configure a destination that resides on Amazon Simple Storage Service (S3) in Splunk Web, TLS certificate validation is not correctly performed and tested for the destination. The vulnerability only affects connections between Splunk Enterprise and an Ingest Actions Destination through Splunk Web and only applies to environments that have configured TLS certificate validation. It does not apply to Destinations configured directly in the outputs.conf configuration file. The vulnerability affects Splunk Enterprise version 9.0.0 and does not affect versions below 9.0.0, including the 8.1.x and 8.2.x versions. | |||||
| CVE-2020-0601 | 2 Golang, Microsoft | 5 Go, Windows, Windows 10 and 2 more | 2022-08-12 | 5.8 MEDIUM | 8.1 HIGH |
| A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates.An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source, aka 'Windows CryptoAPI Spoofing Vulnerability'. | |||||
| CVE-2022-34865 | 1 F5 | 11 Big-ip Access Policy Manager, Big-ip Advanced Firewall Manager, Big-ip Analytics and 8 more | 2022-08-10 | N/A | 9.1 CRITICAL |
| In BIG-IP Versions 15.1.x before 15.1.6.1, 14.1.x before 14.1.5, and all versions of 13.1.x, Traffic Intelligence feeds, which use HTTPS, do not verify the remote endpoint identity, allowing for potential data poisoning. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. | |||||
| CVE-2022-31183 | 1 Typelevel | 1 Fs2 | 2022-08-09 | N/A | 9.8 CRITICAL |
| fs2 is a compositional, streaming I/O library for Scala. When establishing a server-mode `TLSSocket` using `fs2-io` on Node.js, the parameter `requestCert = true` is ignored, peer certificate verification is skipped, and the connection proceeds. The vulnerability is limited to: 1. `fs2-io` running on Node.js. The JVM TLS implementation is completely independent. 2. `TLSSocket`s in server-mode. Client-mode `TLSSocket`s are implemented via a different API. 3. mTLS as enabled via `requestCert = true` in `TLSParameters`. The default setting is `false` for server-mode `TLSSocket`s. It was introduced with the initial Node.js implementation of fs2-io in 3.1.0. A patch is released in v3.2.11. The requestCert = true parameter is respected and the peer certificate is verified. If verification fails, a SSLException is raised. If using an unpatched version on Node.js, do not use a server-mode TLSSocket with requestCert = true to establish a mTLS connection. | |||||
| CVE-2022-1805 | 1 Teradici | 2 Tera2 Pcoip Zero Client, Tera2 Pcoip Zero Client Firmware | 2022-08-05 | N/A | 8.1 HIGH |
| When connecting to Amazon Workspaces, the SHA256 presented by AWS connection provisioner is not fully verified by Zero Clients. The issue could be exploited by an adversary that places a MITM (Man in the Middle) between a zero client and AWS session provisioner in the network. This issue is only applicable when connecting to an Amazon Workspace from a PCoIP Zero Client. | |||||
| CVE-2021-21959 | 1 Sealevel | 2 Seaconnect 370w, Seaconnect 370w Firmware | 2022-07-29 | 6.8 MEDIUM | 8.1 HIGH |
| A misconfiguration exists in the MQTTS functionality of Sealevel Systems, Inc. SeaConnect 370W v1.3.34. This misconfiguration significantly simplifies a man-in-the-middle attack, which directly leads to control of device functionality. | |||||
| CVE-2021-34599 | 1 Codesys | 2 Development System, Git | 2022-07-28 | 5.8 MEDIUM | 7.4 HIGH |
| Affected versions of CODESYS Git in Versions prior to V1.1.0.0 lack certificate validation in HTTPS handshakes. CODESYS Git does not implement certificate validation by default, so it does not verify that the server provides a valid and trusted HTTPS certificate. Since the certificate of the server to which the connection is made is not properly verified, the server connection is vulnerable to a man-in-the-middle attack. | |||||
| CVE-2020-16197 | 1 Octopus | 2 Octopus Server, Server | 2022-07-27 | 4.0 MEDIUM | 4.3 MEDIUM |
| An issue was discovered in Octopus Deploy 3.4. A deployment target can be configured with an Account or Certificate that is outside the scope of the deployment target. An authorised user can potentially use a certificate that they are not in scope to use. An authorised user is also able to obtain certificate metadata by associating a certificate with certain resources that should fail scope validation. | |||||
| CVE-2021-29755 | 2 Ibm, Linux | 2 Qradar Security Information And Event Manager, Linux Kernel | 2022-07-26 | N/A | 7.5 HIGH |
| IBM QRadar SIEM 7.3, 7.4, and 7.5 does not preform proper certificate validation for some inter-host communications. IBM X-Force ID: 202015. | |||||
| CVE-2022-32210 | 1 Nodejs | 1 Undici | 2022-07-25 | N/A | 6.5 MEDIUM |
| `Undici.ProxyAgent` never verifies the remote server's certificate, and always exposes all request & response data to the proxy. This unexpectedly means that proxies can MitM all HTTPS traffic, and if the proxy's URL is HTTP then it also means that nominally HTTPS requests are actually sent via plain-text HTTP between Undici and the proxy server. | |||||
| CVE-2021-22131 | 1 Fortinet | 1 Fortitoken Mobile | 2022-07-25 | N/A | 5.4 MEDIUM |
| A improper validation of certificate with host mismatch in Fortinet FortiTokenAndroid version 5.0.3 and below, Fortinet FortiTokeniOS version 5.2.0 and below, Fortinet FortiTokenWinApp version 4.0.3 and below allows attacker to retrieve information disclosed via man-in-the-middle attacks. | |||||
| CVE-2020-15260 | 1 Teluu | 1 Pjsip | 2022-07-22 | 4.3 MEDIUM | 6.8 MEDIUM |
| PJSIP is a free and open source multimedia communication library written in C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In version 2.10 and earlier, PJSIP transport can be reused if they have the same IP address + port + protocol. However, this is insufficient for secure transport since it lacks remote hostname authentication. Suppose we have created a TLS connection to `sip.foo.com`, which has an IP address `100.1.1.1`. If we want to create a TLS connection to another hostname, say `sip.bar.com`, which has the same IP address, then it will reuse that existing connection, even though `100.1.1.1` does not have certificate to authenticate as `sip.bar.com`. The vulnerability allows for an insecure interaction without user awareness. It affects users who need access to connections to different destinations that translate to the same address, and allows man-in-the-middle attack if attacker can route a connection to another destination such as in the case of DNS spoofing. | |||||
| CVE-2021-22218 | 1 Gitlab | 1 Gitlab | 2022-07-22 | 4.0 MEDIUM | 2.6 LOW |
| All versions of GitLab CE/EE starting from 12.8 before 13.10.5, all versions starting from 13.11 before 13.11.5, and all versions starting from 13.12 before 13.12.2 were affected by an issue in the handling of x509 certificates that could be used to spoof author of signed commits. | |||||
| CVE-2022-31105 | 1 Linuxfoundation | 1 Argo-cd | 2022-07-20 | 5.1 MEDIUM | 9.6 CRITICAL |
| Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD starting with version 0.4.0 and prior to 2.2.11, 2.3.6, and 2.4.5 is vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OpenID Connect (OIDC) provider. A patch for this vulnerability has been released in Argo CD versions 2.4.5, 2.3.6, and 2.2.11. There are no complete workarounds, but a partial workaround is available. Those who use an external OIDC provider (not the bundled Dex instance), can mitigate the issue by setting the `oidc.config.rootCA` field in the `argocd-cm` ConfigMap. This mitigation only forces certificate validation when the API server handles login flows. It does not force certificate verification when verifying tokens on API calls. | |||||
| CVE-2014-8164 | 1 Redhat | 1 Cloudforms Management Engine | 2022-07-14 | 6.4 MEDIUM | 9.1 CRITICAL |
| A insecure configuration for certificate verification (http.verify_mode = OpenSSL::SSL::VERIFY_NONE) may lead to verification bypass in Red Hat CloudForms 5.x. | |||||
| CVE-2021-3162 | 2 Apple, Docker | 2 Macos, Docker | 2022-07-12 | 4.6 MEDIUM | 7.8 HIGH |
| Docker Desktop Community before 2.5.0.0 on macOS mishandles certificate checking, leading to local privilege escalation. | |||||
| CVE-2022-26493 | 1 Drupal | 1 Saml Sp 2.0 Single Sign On | 2022-07-03 | 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-2018-0227 | 1 Cisco | 2 Adaptive Security Appliance Software, Firepower Threat Defense | 2022-06-27 | 5.0 MEDIUM | 7.5 HIGH |
| A vulnerability in the Secure Sockets Layer (SSL) Virtual Private Network (VPN) Client Certificate Authentication feature for Cisco Adaptive Security Appliance (ASA) could allow an unauthenticated, remote attacker to establish an SSL VPN connection and bypass certain SSL certificate verification steps. The vulnerability is due to incorrect verification of the SSL Client Certificate. An attacker could exploit this vulnerability by connecting to the ASA VPN without a proper private key and certificate pair. A successful exploit could allow the attacker to establish an SSL VPN connection to the ASA when the connection should have been rejected. This vulnerability affects Cisco Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) Software that is running on the following Cisco products: 3000 Series Industrial Security Appliances (ISA), ASA 5500 Series Adaptive Security Appliances, ASA 5500-X Series Next-Generation Firewalls, ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers, Adaptive Security Virtual Appliances (ASAv), Firepower 4110 Security Appliances, Firepower 9300 ASA Security Modules. Cisco Bug IDs: CSCvg40155. | |||||
| CVE-2022-32151 | 1 Splunk | 2 Splunk, Splunk Cloud Platform | 2022-06-24 | 6.4 MEDIUM | 9.1 CRITICAL |
| The httplib and urllib Python libraries that Splunk shipped with Splunk Enterprise did not validate certificates using the certificate authority (CA) certificate stores by default in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203. Python 3 client libraries now verify server certificates by default and use the appropriate CA certificate stores for each library. Apps and add-ons that include their own HTTP libraries are not affected. 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-32152 | 1 Splunk | 2 Splunk, Splunk Cloud Platform | 2022-06-24 | 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. | |||||