| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Libgcrypt before 1.8.8 and 1.9.x before 1.9.3 mishandles ElGamal encryption because it lacks exponent blinding to address a side-channel attack against mpi_powm, and the window size is not chosen appropriately. This, for example, affects use of ElGamal in OpenPGP. |
| A user can tell curl >= 7.20.0 and <= 7.78.0 to require a successful upgrade to TLS when speaking to an IMAP, POP3 or FTP server (`--ssl-reqd` on the command line or`CURLOPT_USE_SSL` set to `CURLUSESSL_CONTROL` or `CURLUSESSL_ALL` withlibcurl). This requirement could be bypassed if the server would return a properly crafted but perfectly legitimate response.This flaw would then make curl silently continue its operations **withoutTLS** contrary to the instructions and expectations, exposing possibly sensitive data in clear text over the network. |
| A flaw was found in Nettle in versions before 3.7.2, where several Nettle signature verification functions (GOST DSA, EDDSA & ECDSA) result in the Elliptic Curve Cryptography point (ECC) multiply function being called with out-of-range scalers, possibly resulting in incorrect results. This flaw allows an attacker to force an invalid signature, causing an assertion failure or possible validation. The highest threat to this vulnerability is to confidentiality, integrity, as well as system availability. |
| GnuTLS 3.6.x before 3.6.14 uses incorrect cryptography for encrypting a session ticket (a loss of confidentiality in TLS 1.2, and an authentication bypass in TLS 1.3). The earliest affected version is 3.6.4 (2018-09-24) because of an error in a 2018-09-18 commit. Until the first key rotation, the TLS server always uses wrong data in place of an encryption key derived from an application. |
| GnuTLS 3.6.x before 3.6.13 uses incorrect cryptography for DTLS. The earliest affected version is 3.6.3 (2018-07-16) because of an error in a 2017-10-06 commit. The DTLS client always uses 32 '\0' bytes instead of a random value, and thus contributes no randomness to a DTLS negotiation. This breaks the security guarantees of the DTLS protocol. |
| Snowy 3.6.5 contains a hard-coded HMAC key vulnerability that allows unauthenticated attackers to forge download signatures for the /dev/file/download endpoint by using the published FILE_DOWNLOAD_SIGN_SECRET constant. Attackers can compute HMAC-SHA256 signatures of guessed file ids offline to download stored files such as avatars, editor images and attachments. |
| A use of hard-coded cryptographic key vulnerability in Fortinet FortiSandbox 5.2.0 through 5.2.1, FortiSandbox 5.0.0 through 5.0.6, FortiSandbox 4.4 all versions, FortiSandbox Cloud 5.2.0 through 5.2.1, FortiSandbox Cloud 5.0.0 through 5.0.6, FortiSandbox Cloud 4.4 all versions may allow attacker to escalation of privilege via specially crafted HTTP requests |
| NetEase Cloud Music client for Windows (cloudmusic.exe) versions 3.1.38 and 3.1.39.205426 contains a weak encryption vulnerability where /eapi/ and /xeapi/ API response bodies are decrypted using a fixed, publicly documented AES-128-ECB key with no integrity credential. Attackers who can intercept or originate server responses can construct valid ciphertext under the known key with PKCS#7 padding, enabling the client to accept forged API responses that serve as a prerequisite for further exploitation such as reaching the os.navigateExternal bridge. |
| NVIDIA Megatron-LM for all platforms contains a vulnerability in inference, where an attacker could cause hash collisions in the cache used for inference requests. A successful exploit of this vulnerability might lead to data tampering and partial information disclosure. |
| A vulnerability has been identified in blueplanet 100 NX3 M8 (All versions), blueplanet 100 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 105 TL3 (All versions < V3.92), blueplanet 105 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 110 TL3 (All versions < V3.92), blueplanet 125 NX3 M10 (All versions), blueplanet 125 TL3 (All versions < V3.92), blueplanet 125 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 137 TL3 (All versions < V3.92), blueplanet 150 TL3 (All versions < V3.92), blueplanet 150 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 155 TL3 (All versions < V3.92), blueplanet 155 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 165 TL3 (All versions < V3.92), blueplanet 165 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 3.0 TL3-60.0 TL3 (All versions), blueplanet 87.0 TL3 (All versions < V3.92), blueplanet 87.0 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 92.0 TL3 (All versions < V3.92), blueplanet 92.0 TL3 GEN2 (All versions < V6.1.4.9), blueplanet gridsave 110 TL3-S (All versions < V3.91), blueplanet gridsave 137 TL3-S (All versions < V3.91), blueplanet gridsave 92.0 TL3-S (All versions < V3.91). A CRC16-based algorithm for generating Technical Service credentials could allow an attacker to derive the credentials from the devices serial number and misuse them to gain unauthorized access. |
| In Progress ShareFile Storage Zones Controller v5.12.6 and below, processing of queue items can send acknowledgements to an unvalidated callback URL, this behavior together with a race condition allows the attacker to cause FileCopyService to consume attacker-controlled metadata and content. Exploitation requires control over copy queue work and a race condition. |
| Crux Agent from 1.9.0 before 2.0.3 uses the full SKA bilocation key as the WireGuard preshared key. When a peering session negotiates use of SHA-512, the key produced is 64 bytes instead of the 32 bytes WireGuard requires. The agent does not validate this size; instead it attempts to use the `wg set` command to update the live tunnel, and write the invalid key to the WireGuard configuration file. The update fails, so the live tunnel keeps using its previous preshared key until the tunnel is shut down. The tunnel will fail to start when restarted.
For a peer which has never successfully negotiated a 32-byte bilocation key in a Crux C2 organization which has the "Enforce SKA Use" setting turned off, no preshared key will be set for the tunnel. Therefore, an attacker who is able to intercept and store the peer's traffic, and has access (or will have access) to a cryptographically relevant quantum computer, will be able to decrypt the tunnel. |
| The SSL protocol, as used in certain configurations in Microsoft Windows and Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Opera, and other products, encrypts data by using CBC mode with chained initialization vectors, which allows man-in-the-middle attackers to obtain plaintext HTTP headers via a blockwise chosen-boundary attack (BCBA) on an HTTPS session, in conjunction with JavaScript code that uses (1) the HTML5 WebSocket API, (2) the Java URLConnection API, or (3) the Silverlight WebClient API, aka a "BEAST" attack. |
| Dell Command | Configure (DCC), versions prior to 5.2.3.35 contain a Use of Hard-coded Cryptographic Key vulnerability. An unauthenticated attacker with local access could potentially exploit this vulnerability, leading to Information disclosure. |
| Use of hard-coded cryptographic key vulnerability in Johnson Controls ADVMS allows Read Sensitive Constants Within an Executable.
This issue affects ADVMS: before 3.10. |
| The Booking Calendar WordPress plugin before 11.8 does not generate its per-booking access hashes with sufficient entropy, deriving each from a low-entropy time-seeded value, which can allow unauthenticated attackers who are able to determine a booking's creation time to predict the hash and then read that booking's personal data or modify the booking in place. |
| An issue was discovered in the ALFA Windows 10 driver 6.1316.1209 for AWUS036H. The WEP, WPA, WPA2, and WPA3 implementations accept plaintext frames in a protected Wi-Fi network. An adversary can abuse this to inject arbitrary data frames independent of the network configuration. |
| The OpenSSL ECDSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Fixed in OpenSSL 1.1.0j (Affected 1.1.0-1.1.0i). Fixed in OpenSSL 1.1.1a (Affected 1.1.1). |
| The OpenSSL DSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Fixed in OpenSSL 1.1.1a (Affected 1.1.1). Fixed in OpenSSL 1.1.0j (Affected 1.1.0-1.1.0i). Fixed in OpenSSL 1.0.2q (Affected 1.0.2-1.0.2p). |
| During key agreement in a TLS handshake using a DH(E) based ciphersuite a malicious server can send a very large prime value to the client. This will cause the client to spend an unreasonably long period of time generating a key for this prime resulting in a hang until the client has finished. This could be exploited in a Denial Of Service attack. Fixed in OpenSSL 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev (Affected 1.0.2-1.0.2o). |
