|
|
Search Results
There are 19 CVE Records that match your search.
| Name | Description |
|---|---|
| CVE-2024-37307 | Cilium is a networking, observability, and security solution with an eBPF-based dataplane. Starting in version 1.13.0 and prior to versions 1.13.7, 1.14.12, and 1.15.6, the output of `cilium-bugtool` can contain sensitive data when the tool is run (with the `--envoy-dump` flag set) against Cilium deployments with the Envoy proxy enabled. Users of the TLS inspection, Ingress with TLS termination, Gateway API with TLS termination, and Kafka network policies with API key filtering features are affected. The sensitive data includes the CA certificate, certificate chain, and private key used by Cilium HTTP Network Policies, and when using Ingress/Gateway API and the API keys used in Kafka-related network policy. `cilium-bugtool` is a debugging tool that is typically invoked manually and does not run during the normal operation of a Cilium cluster. This issue has been patched in Cilium v1.15.6, v1.14.12, and v1.13.17. There is no workaround to this issue. |
| CVE-2022-4203 | A read buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. The read buffer overrun might result in a crash which could lead to a denial of service attack. In theory it could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext) although we are not aware of any working exploit leading to memory contents disclosure as of the time of release of this advisory. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. |
| CVE-2021-40831 | 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. |
| CVE-2021-40830 | 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 Unix systems. 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 override the default trust store. This corrects this issue. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.6.1 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.12.7 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.5.3 on Linux/Unix. Amazon Web Services AWS-C-IO 0.10.4 on Linux/Unix. |
| CVE-2021-29792 | IBM Event Streams 10.0, 10.1, 10.2, and 10.3 could allow a user the CA private key to create their own certificates and deploy them in the cluster and gain privileges of another user. IBM X-Force ID: 203450. |
| CVE-2020-28053 | HashiCorp Consul and Consul Enterprise 1.2.0 up to 1.8.5 allowed operators with operator:read ACL permissions to read the Connect CA private key configuration. Fixed in 1.6.10, 1.7.10, and 1.8.6. |
| CVE-2019-1590 | A vulnerability in the Transport Layer Security (TLS) certificate validation functionality of Cisco Nexus 9000 Series Application Centric Infrastructure (ACI) Mode Switch Software could allow an unauthenticated, remote attacker to perform insecure TLS client authentication on an affected device. The vulnerability is due to insufficient TLS client certificate validations for certificates sent between the various components of an ACI fabric. An attacker who has possession of a certificate that is trusted by the Cisco Manufacturing CA and the corresponding private key could exploit this vulnerability by presenting a valid certificate while attempting to connect to the targeted device. An exploit could allow the attacker to gain full control of all other components within the ACI fabric of an affected device. |
| CVE-2018-1841 | IBM Cloud Private 2.1.0 could allow a local user to obtain the CA Private Key due to it being world readable in boot/master node. IBM X-Force ID: 150901. |
| CVE-2018-17612 | Sennheiser HeadSetup 7.3.4903 places Certification Authority (CA) certificates into the Trusted Root CA store of the local system, and publishes the private key in the SennComCCKey.pem file within the public software distribution, which allows remote attackers to spoof arbitrary web sites or software publishers for several years, even if the HeadSetup product is uninstalled. NOTE: a vulnerability-assessment approach must check all Windows systems for CA certificates with a CN of 127.0.0.1 or SennComRootCA, and determine whether those certificates are unwanted. |
| CVE-2017-6339 | Trend Micro InterScan Web Security Virtual Appliance (IWSVA) 6.5 before CP 1746 mismanages certain key and certificate data. Per IWSVA documentation, by default, IWSVA acts as a private Certificate Authority (CA) and dynamically generates digital certificates that are sent to client browsers to complete a secure passage for HTTPS connections. It also allows administrators to upload their own certificates signed by a root CA. An attacker with low privileges can download the current CA certificate and Private Key (either the default ones or ones uploaded by administrators) and use those to decrypt HTTPS traffic, thus compromising confidentiality. Also, the default Private Key on this appliance is encrypted with a very weak passphrase. If an appliance uses the default Certificate and Private Key provided by Trend Micro, an attacker can simply download these and decrypt the Private Key using the default/weak passphrase. |
| CVE-2016-3095 | server/bin/pulp-gen-ca-certificate in Pulp before 2.8.2 allows local users to read the generated private key. |
| CVE-2015-7328 | Puppet Server in Puppet Enterprise before 3.8.x before 3.8.3 and 2015.2.x before 2015.2.3 uses world-readable permissions for the private key of the Certification Authority (CA) certificate during the initial installation and configuration, which might allow local users to obtain sensitive information via unspecified vectors. |
| CVE-2015-5284 | ipa-kra-install in FreeIPA before 4.2.2 puts the CA agent certificate and private key in /etc/httpd/alias/kra-agent.pem, which is world readable. |
| CVE-2015-2077 | The SDK for Komodia Redirector with SSL Digestor, as used in Lavasoft Ad-Aware Web Companion 1.1.885.1766 and Ad-Aware AdBlocker (alpha) 1.3.69.1, Qustodio for Windows, Atom Security, Inc. StaffCop 5.8, and other products, uses the same X.509 certificate private key for a root CA certificate across different customers' installations, which makes it easier for man-in-the-middle attackers to spoof SSL servers by leveraging knowledge of this key, as originally reported for Superfish VisualDiscovery on certain Lenovo Notebook laptop products. |
| CVE-2014-2734 | ** DISPUTED ** The openssl extension in Ruby 2.x does not properly maintain the state of process memory after a file is reopened, which allows remote attackers to spoof signatures within the context of a Ruby script that attempts signature verification after performing a certain sequence of filesystem operations. NOTE: this issue has been disputed by the Ruby OpenSSL team and third parties, who state that the original demonstration PoC contains errors and redundant or unnecessarily-complex code that does not appear to be related to a demonstration of the issue. As of 20140502, CVE is not aware of any public comment by the original researcher. |
| CVE-2012-4948 | The default configuration of Fortinet Fortigate UTM appliances uses the same Certification Authority certificate and same private key across different customers' installations, which makes it easier for man-in-the-middle attackers to spoof SSL servers by leveraging the presence of the Fortinet_CA_SSLProxy certificate in a list of trusted root certification authorities. |
| CVE-2012-3372 | ** DISPUTED ** The default configuration of Cyberoam UTM appliances uses the same Certification Authority certificate and same private key across different customers' installations, which makes it easier for man-in-the-middle attackers to spoof SSL servers by leveraging the presence of the Cyberoam_SSL_CA certificate in a list of trusted root certification authorities. NOTE: the vendor disputes the significance of this issue because the appliance "does not allow import or export of the foresaid private key." |
| CVE-2012-3037 | The Siemens SIMATIC S7-1200 2.x PLC does not properly protect the private key of the SIMATIC CONTROLLER Certification Authority certificate, which allows remote attackers to spoof the S7-1200 web server by using this key to create a forged certificate. |
| CVE-2011-4197 | etc/inc/certs.inc in the PKI implementation in pfSense before 2.0.1 creates each X.509 certificate with a true value for the CA basic constraint, which allows remote attackers to create sub-certificates for arbitrary subjects by leveraging the private key. |
|
You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select “Other” from dropdown)
|
||
