| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| In Bouncy Castle for Java LTS before 2.73.13, the native one-shot CTR packet cipher did not check that the requested input length fitted the counter space the IV left. In CTR mode the IV and the block counter share one 16-byte block, so an IV of 13 to 15 bytes leaves a counter of only 1 to 3 bytes, addressing 256, 65536 or 16777216 blocks respectively. Given a longer input the counter wrapped and the keystream repeated from the start of the same packet, and the call then returned the full input length as though every byte had been correctly transformed. Two segments of the message were therefore encrypted under the same keystream, so their plaintexts can be recovered from the ciphertext alone, without the key, while the caller saw neither an exception nor a short length to indicate it. The streaming implementation validates at init and again while processing, and the portable AESCTRPacketCipher rejects such a request with "Counter in CTR/SIC mode out of range.", but the native one-shot path has a single entry point and performed no counter-range validation there. It now preflights the IV-derived counter range and rejects an over-long request before any output is written, so the operation is failure-atomic and never reports success for bytes it did not correctly transform. A counter of four bytes or more cannot be exhausted by a Java int length and is unaffected, as is a full 16-byte IV, where the counter range is the caller's responsibility. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations. |
| 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. |
| A vulnerability in the SupportLink API authentication component of Brocade ASCG versions prior to 3.5.0 allows an attacker to bypass authentication across deployments due to the use of a hard coded cryptographic key. |
| 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). |
| Using its HSTS support, curl can be instructed to use HTTPS directly insteadof using an insecure clear-text HTTP step even when HTTP is provided in theURL. This mechanism could be bypassed if the host name in the given URL used atrailing dot while not using one when it built the HSTS cache. Or the otherway around - by having the trailing dot in the HSTS cache and *not* using thetrailing dot in the URL. |
| FFmpeg through 9.0.2 contains a missing host key verification vulnerability in the libssh-based sftp protocol handler that allows network attackers to impersonate SFTP servers. Attackers performing man-in-the-middle, DNS, or ARP spoofing can capture passwords supplied in sftp URLs, serve forged media, or receive uploaded output. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to obtain sensitive information due to the use of a hard-coded or predictable cryptographic key. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote authenticated attacker to obtain sensitive information and forge authentication tags due to the use of hard-coded cryptographic keys and initialization vectors. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to bypass authentication and access sensitive information due to a hard-coded cryptographic key. |
| A vulnerability has been found in Lybbn Django-Vue-Lyadmin up to 3.2.12. The impacted element is an unknown function of the file backend/application/settings.py of the component JWT Signing. The manipulation of the argument SECRET_KEY leads to use of hard-coded cryptographic key
. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used. The project maintainer explains: "The issue with this key is described in the documentation. Developers need to manually change their keys before deployment." |
| Dell OpenManage Server Administrator, versions prior to 11.1.0.3, contains a Use of Hard-coded Cryptographic Key vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Unauthorized access. |
| This vulnerability exists in the Schmooze app due to the use of hardcoded credentials and cryptographic keys in the client application. An unauthenticated remote attacker could exploit this vulnerability by decompiling the distributed application package and extracting the embedded credentials and cryptographic keys.
Successful exploitation of this vulnerability could allow the attacker to gain unauthorized access to backend and cloud resources and forge client requests on the targeted system. |
| A weakness has been identified in YzmCMS up to 7.6. Impacted is the function Password of the file /common/function/system.func.php of the component MD5 Handler. Executing a manipulation of the argument pass can lead to password hash with insufficient computational effort. The attack may be launched remotely. This attack is characterized by high complexity. The exploitability is considered difficult. The exploit has been made available to the public and could be used for attacks. The vendor kindly explains: "Our regular release cycle is about 6 months. The last release was in the previous month, and our next scheduled version will be released in March 2027. We will implement the backward-compatible gradual hash migration feature in this upcoming release. (...) Before the new version is available, we will publish security mitigation guidance on our official documentation for existing deployers to reduce the risk." |
| Armatura One stores database and message-broker credentials in an install configuration file, encrypting them with AES-128-CBC when this protection is enabled. The encryption key and initialization vector are fixed values embedded in the software itself and are identical across every installation. An attacker with a copy of the installation package can recover this key and initialization vector, and can then decrypt the stored credentials of any specific installation to which the attacker separately obtains the encrypted configuration file. |
