| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| wlc is a Weblate command-line client using Weblate's REST API. Prior to 1.17.0, the SSL verification would be skipped for some crafted URLs. This vulnerability is fixed in 1.17.0. |
| dcap-qvl implements the quote verification logic for DCAP (Data Center Attestation Primitives). A vulnerability present in versions prior to 0.3.9 involves a critical gap in the cryptographic verification process within the dcap-qvl. The library fetches QE Identity collateral (including qe_identity, qe_identity_signature, and qe_identity_issuer_chain) from the PCCS. However, it skips to verify the QE Identity signature against its certificate chain and does not enforce policy constraints on the QE Report. An attacker can forge the QE Identity data to whitelist a malicious or non-Intel Quoting Enclave. This allows the attacker to forge the QE and sign untrusted quotes that the verifier will accept as valid. Effectively, this bypasses the entire remote attestation security model, as the verifier can no longer trust the entity responsible for signing the quotes. All deployments utilizing the dcap-qvl library for SGX or TDX quote verification are affected. The vulnerability has been patched in dcap-qvl version 0.3.9. The fix implements the missing cryptographic verification for the QE Identity signature and enforces the required checks for MRSIGNER, ISVPRODID, and ISVSVN against the QE Report. Users of the `@phala/dcap-qvl-node` and `@phala/dcap-qvl-web` packages should switch to the pure JavaScript implementation, `@phala/dcap-qvl`. There are no known workarounds for this vulnerability. Users must upgrade to the patched version to ensure that QE Identity collateral is properly verified. |
| An Improper Certificate Validation vulnerability in the OPC-UA client and ANSL over TLS client used in Automation Studio versions before 6.5 could allow an unauthenticated attacker on the network to position themselves to intercept and interfere with data exchanges. |
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Security). Supported versions that are affected are Oracle Java SE: 8u471, 8u471-b50, 8u471-perf, 11.0.29, 17.0.17, 21.0.9, 25.0.1; Oracle GraalVM for JDK: 17.0.17 and 21.0.9; Oracle GraalVM Enterprise Edition: 21.3.16. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). |
| Altium Designer version 24.9.0 does not validate self-signed server certificates for cloud connections. An attacker capable of performing a man-in-the-middle (MITM) attack could exploit this issue to intercept or manipulate network traffic, potentially exposing authentication credentials or sensitive design data. |
| The Infotainment ECU manufactured by Bosch which is installed in Nissan Leaf ZE1 – 2020 uses a Redbend service for over-the-air provisioning and updates. HTTPS is used for communication with the back-end server. Due to usage of the default configuration for the underlying SSL engine, the server root certificate is not verified. As a result, an attacker may be able to impersonate a Redbend backend server using a self-signed certificate.
First identified on Nissan Leaf ZE1 manufactured in 2020. |
| An improper certificate validation vulnerability exists in ToDesktop Builder v0.32.1 This vulnerability allows an unauthenticated, on-path attacker to spoof backend responses by exploiting insufficient certificate validation. |
| The communication protocol used between client
and server had a flaw that could be leveraged to execute a man in the middle attack. |
| An improper certificate validation vulnerability has been reported to affect Helpdesk. If exploited, the vulnerability could allow remote attackers to compromise the security of the system.
We have already fixed the vulnerability in the following version:
Helpdesk 3.3.3 and later |
| An issue in Automai BotManager v.25.2.0 allows a remote attacker to execute arbitrary code via the BotManager.exe component |
| When using `CURLOPT_PINNEDPUBLICKEY` option with libcurl or `--pinnedpubkey`
with the curl tool,curl should check the public key of the server certificate
to verify the peer.
This check was skipped in a certain condition that would then make curl allow
the connection without performing the proper check, thus not noticing a
possible impostor. To skip this check, the connection had to be done with QUIC
with ngtcp2 built to use GnuTLS and the user had to explicitly disable the
standard certificate verification. |
| When doing TLS related transfers with reused easy or multi handles and
altering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally
reuse a CA store cached in memory for which the partial chain option was
reversed. Contrary to the user's wishes and expectations. This could make
libcurl find and accept a trust chain that it otherwise would not. |
| The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName configuration attribute or the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property is set to true.
This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions:
* The attacker is able to intercept or redirect network traffic between the client and the log receiver.
* The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured).
Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue.
As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. |
| No description is available for this CVE. |
| Cybersecurity Nozomi Networks Labs, a specialized security company focused on Industrial Control Systems (ICS) and OT/IoT security, has found a flaw that camera's client service does not perform certificate validation. The manufacturer has released patch firmware for the flaw, please refer to the manufacturer's report for details and workarounds. |
| Aqara Hub devices including Hub M2 4.3.6_0027, Hub M3 4.3.6_0025, Camera Hub G3 4.1.9_0027 fail to validate server certificates in TLS connections for discovery services and CoAP gateway communications, enabling man-in-the-middle attacks on device control and monitoring. |
| An improper certificate validation vulnerability [CWE-295] in FortiOS 6.2 all versions, 6.4 all versions, 7.0.0 through 7.0.10, 7.2.0 and FortiProxy 1.2 all versions, 2.0 all versions, 7.0.0 through 7.0.9, 7.2.0 through 7.2.3 may allow a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the communication channel between the vulnerable device and the remote FortiGuard's map server. |
| An improper certificate validation vulnerability in Fortinet FortiOS 7.4.0 through 7.4.1, FortiOS 7.2.0 through 7.2.6, FortiOS 7.0.0 through 7.0.15, FortiOS 6.4 all versions allows a remote and unauthenticated attacker to perform a Man-in-the-Middle attack on the FortiLink communication channel between the FortiOS device and FortiSwitch. |
| Improper certificate validation in certain Zoom Clients may allow an unauthenticated user to conduct a disclosure of information via adjacent access. |
| Errands before 46.2.10 does not verify TLS certificates for CalDAV servers. |
