Total
977 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-33684 | 1 Apache | 1 Pulsar | 2023-01-26 | 8.1 High |
| The Apache Pulsar C++ Client does not verify peer TLS certificates when making HTTPS calls for the OAuth2.0 Client Credential Flow, even when tlsAllowInsecureConnection is disabled via configuration. This vulnerability allows an attacker to perform a man in the middle attack and intercept and/or modify the GET request that is sent to the ClientCredentialFlow 'issuer url'. The intercepted credentials can be used to acquire authentication data from the OAuth2.0 server to then authenticate with an Apache Pulsar cluster. 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. The Apache Pulsar Python Client wraps the C++ client, so it is also vulnerable in the same way. This issue affects Apache Pulsar C++ Client and Python 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 to 2.10.1; 2.6.4 and earlier. Any users running affected versions of the C++ Client or the Python Client should rotate vulnerable OAuth2.0 credentials, including client_id and client_secret. 2.7 C++ and Python Client users should upgrade to 2.7.5 and rotate vulnerable OAuth2.0 credentials. 2.8 C++ and Python Client users should upgrade to 2.8.4 and rotate vulnerable OAuth2.0 credentials. 2.9 C++ and Python Client users should upgrade to 2.9.3 and rotate vulnerable OAuth2.0 credentials. 2.10 C++ and Python Client users should upgrade to 2.10.2 and rotate vulnerable OAuth2.0 credentials. 3.0 C++ users are unaffected and 3.0 Python Client users will be unaffected when it is released. Any users running the C++ and Python Client for 2.6 or less should upgrade to one of the above patched versions. | ||||
| CVE-2021-29726 | 1 Ibm | 2 Secure External Authentication Server, Sterling Secure Proxy | 2023-01-24 | 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-2020-36477 | 1 Arm | 1 Mbed Tls | 2023-01-13 | 5.9 Medium |
| An issue was discovered in Mbed TLS before 2.24.0. The verification of X.509 certificates when matching the expected common name (the cn argument of mbedtls_x509_crt_verify) with the actual certificate name is mishandled: when the subjecAltName extension is present, the expected name is compared to any name in that extension regardless of its type. This means that an attacker could impersonate a 4-byte or 16-byte domain by getting a certificate for the corresponding IPv4 or IPv6 address (this would require the attacker to control that IP address, though). | ||||
| CVE-2020-36425 | 2 Arm, Debian | 2 Mbed Tls, Debian Linux | 2023-01-11 | 5.3 Medium |
| An issue was discovered in Arm Mbed TLS before 2.24.0. It incorrectly uses a revocationDate check when deciding whether to honor certificate revocation via a CRL. In some situations, an attacker can exploit this by changing the local clock. | ||||
| CVE-2020-36478 | 3 Arm, Debian, Siemens | 14 Mbed Tls, Debian Linux, Logo\! Cmr2020 and 11 more | 2023-01-11 | 7.5 High |
| An issue was discovered in Mbed TLS before 2.25.0 (and before 2.16.9 LTS and before 2.7.18 LTS). A NULL algorithm parameters entry looks identical to an array of REAL (size zero) and thus the certificate is considered valid. However, if the parameters do not match in any way, then the certificate should be considered invalid. | ||||
| CVE-2020-9868 | 1 Apple | 5 Ipados, Iphone Os, Mac Os X and 2 more | 2023-01-09 | 9.1 Critical |
| A certificate validation issue existed when processing administrator added certificates. This issue was addressed with improved certificate validation. This issue is fixed in iOS 13.6 and iPadOS 13.6, macOS Catalina 10.15.6, tvOS 13.4.8, watchOS 6.2.8. An attacker may have been able to impersonate a trusted website using shared key material for an administrator added certificate. | ||||
| CVE-2022-45419 | 1 Mozilla | 1 Firefox | 2023-01-04 | 6.5 Medium |
| If the user added a security exception for an invalid TLS certificate, opened an ongoing TLS connection with a server that used that certificate, and then deleted the exception, Firefox would have kept the connection alive, making it seem like the certificate was still trusted. This vulnerability affects Firefox < 107. | ||||
| CVE-2022-34469 | 2 Google, Mozilla | 2 Android, Firefox | 2023-01-04 | 8.1 High |
| When a TLS Certificate error occurs on a domain protected by the HSTS header, the browser should not allow the user to bypass the certificate error. On Firefox for Android, the user was presented with the option to bypass the error; this could only have been done by the user explicitly. <br>*This bug only affects Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox < 102. | ||||
| CVE-2022-22747 | 1 Mozilla | 3 Firefox, Firefox Esr, Thunderbird | 2022-12-29 | 6.5 Medium |
| After accepting an untrusted certificate, handling an empty pkcs7 sequence as part of the certificate data could have lead to a crash. This crash is believed to be unexploitable. This vulnerability affects Firefox ESR < 91.5, Firefox < 96, and Thunderbird < 91.5. | ||||
| CVE-2022-1197 | 1 Mozilla | 1 Thunderbird | 2022-12-29 | 5.4 Medium |
| When importing a revoked key that specified key compromise as the revocation reason, Thunderbird did not update the existing copy of the key that was not yet revoked, and the existing key was kept as non-revoked. Revocation statements that used another revocation reason, or that didn't specify a revocation reason, were unaffected. This vulnerability affects Thunderbird < 91.8. | ||||
| CVE-2022-1834 | 1 Mozilla | 1 Thunderbird | 2022-12-29 | 6.5 Medium |
| When displaying the sender of an email, and the sender name contained the Braille Pattern Blank space character multiple times, Thunderbird would have displayed all the spaces. This could have been used by an attacker to send an email message with the attacker's digital signature, that was shown with an arbitrary sender email address chosen by the attacker. If the sender name started with a false email address, followed by many Braille space characters, the attacker's email address was not visible. Because Thunderbird compared the invisible sender address with the signature's email address, if the signing key or certificate was accepted by Thunderbird, the email was shown as having a valid digital signature. This vulnerability affects Thunderbird < 91.10. | ||||
| CVE-2022-1632 | 2 Fedoraproject, Redhat | 3 Fedora, Ansible Automation Platform, Openshift Container Platform | 2022-12-13 | 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-2996 | 2 Debian, Python-scciclient Project | 2 Debian Linux, Python-scciclient | 2022-12-12 | 7.4 High |
| A flaw was found in the python-scciclient when making an HTTPS connection to a server where the server's certificate would not be verified. This issue opens up the connection to possible Man-in-the-middle (MITM) attacks. | ||||
| CVE-2022-46153 | 1 Traefik | 1 Traefik | 2022-12-12 | 6.5 Medium |
| Traefik is an open source HTTP reverse proxy and load balancer. In affected versions there is a potential vulnerability in Traefik managing TLS connections. A router configured with a not well-formatted TLSOption is exposed with an empty TLSOption. For instance, a route secured using an mTLS connection set with a wrong CA file is exposed without verifying the client certificates. Users are advised to upgrade to version 2.9.6. Users unable to upgrade should check their logs to detect the error messages and fix your TLS options. | ||||
| CVE-2022-41316 | 1 Hashicorp | 1 Vault | 2022-12-03 | 5.3 Medium |
| HashiCorp Vault and Vault Enterprise’s TLS certificate auth method did not initially load the optionally configured CRL issued by the role's CA into memory on startup, resulting in the revocation list not being checked if the CRL has not yet been retrieved. Fixed in 1.12.0, 1.11.4, 1.10.7, and 1.9.10. | ||||
| CVE-2020-5913 | 1 F5 | 14 Big-ip Access Policy Manager, Big-ip Advanced Firewall Manager, Big-ip Advanced Web Application Firewall and 11 more | 2022-12-03 | 7.4 High |
| In versions 15.0.0-15.1.0.1, 14.1.0-14.1.2.3, 13.1.0-13.1.3.4, 12.1.0-12.1.5.1, and 11.6.1-11.6.5.2, the BIG-IP Client or Server SSL profile ignores revoked certificates, even when a valid CRL is present. This impacts SSL/TLS connections and may result in a man-in-the-middle attack on the connections. | ||||
| CVE-2022-43705 | 1 Botan Project | 1 Botan | 2022-12-01 | 9.1 Critical |
| In Botan before 2.19.3, it is possible to forge OCSP responses due to a certificate verification error. This issue was introduced in Botan 1.11.34 (November 2016). | ||||
| CVE-2020-35509 | 1 Redhat | 1 Keycloak | 2022-12-01 | 5.4 Medium |
| A flaw was found in keycloak affecting versions 11.0.3 and 12.0.0. An expired certificate would be accepted by the direct-grant authenticator because of missing time stamp validations. The highest threat from this vulnerability is to data confidentiality and integrity. | ||||
| CVE-2020-26184 | 2 Dell, Oracle | 4 Bsafe Micro-edition-suite, Http Server, Security Service and 1 more | 2022-11-29 | 7.5 High |
| Dell BSAFE Micro Edition Suite, versions prior to 4.5.1, contain an Improper Certificate Validation vulnerability. | ||||
| CVE-2022-23632 | 2 Oracle, Traefik | 2 Communications Unified Inventory Management, Traefik | 2022-11-23 | 7.5 High |
| Traefik is an HTTP reverse proxy and load balancer. Prior to version 2.6.1, Traefik skips the router transport layer security (TLS) configuration when the host header is a fully qualified domain name (FQDN). For a request, the TLS configuration choice can be different than the router choice, which implies the use of a wrong TLS configuration. When sending a request using FQDN handled by a router configured with a dedicated TLS configuration, the TLS configuration falls back to the default configuration that might not correspond to the configured one. If the CNAME flattening is enabled, the selected TLS configuration is the SNI one and the routing uses the CNAME value, so this can skip the expected TLS configuration. Version 2.6.1 contains a patch for this issue. As a workaround, one may add the FDQN to the host rule. However, there is no workaround if the CNAME flattening is enabled. | ||||