A vulnerability was determined in Beetel 777VR1 up to 01.00.09. This impacts an unknown function of the component SSH Service. This manipulation causes risky cryptographic algorithm. The attack is possible to be carried out remotely. The attack is considered to have high complexity. The exploitability is said to be difficult. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.

Clatter is a no_std compatible, pure Rust implementation of the Noise protocol framework with post-quantum support. Versiosn prior to2.2.0 have a protocol compliance vulnerability. The library allowed post-quantum handshake patterns that violated the PSK validity rule (Noise Protocol Framework Section 9.3). This could allow PSK-derived keys to be used for encryption without proper randomization by self-chosen ephemeral randomness, weakening security guarantees and potentially allowing catastrophic key reuse. Affected default patterns include `noise_pqkk_psk0`, `noise_pqkn_psk0`, `noise_pqnk_psk0`, `noise_pqnn_psk0``, and some hybrid variants. Users of these patterns may have been using handshakes that do not meet the intended security properties. The issue is fully patched and released in Clatter v2.2.0. The fixed version includes runtime checks to detect offending handshake patterns. As a workaround, avoid using offending `*_psk0` variants of post-quantum patterns. Review custom handshake patterns carefully.

YesWiki is a wiki system written in PHP. Prior to 4.4.5, the use of a weak cryptographic algorithm and a hard-coded salt to hash the password reset key allows it to be recovered and used to reset the password of any account. This issue is fixed in 4.4.5.

An attacker may exploit the use of weak CBC-based cipher suites in the device’s SSH service to potentially observe or manipulate parts of the encrypted SSH communication, if they are able to intercept or interact with the network traffic.

A cryptanalytic break in Altcha Proof-of-Work obfuscation mode version 0.8.0 and later allows for remote visitors to recover the Proof-of-Work nonce in constant time via mathematical deduction. NOTE: this is disputed by the Supplier because the product's objective is "to discourage automated scraping / bots, not guarantee resistance to determined attackers." The documentation states “the goal is not to provide a secure cryptographic algorithm but to use a proof-of-work mechanism that allows any capable device to decrypt the hidden data.”

PyJWT is a Python implementation of RFC 7519. PyJWT supports multiple different JWT signing algorithms. With JWT, an attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify `jwt.algorithms.get_default_algorithms()` to get support for all algorithms, or specify a single algorithm. The issue is not that big as `algorithms=jwt.algorithms.get_default_algorithms()` has to be used. Users should upgrade to v2.4.0 to receive a patch for this issue. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

DeviceFarmer stf v3.6.6 suffers from Use of a Broken or Risky Cryptographic Algorithm.

HCL DRYiCE MyXalytics is impacted by the use of an insecure key rotation mechanism which can allow an attacker to compromise the confidentiality or integrity of data.

An issue was discovered in bcoin-org bcoin version 2.2.0, allows remote attackers to obtain sensitive information via weak hashing algorithms in the component \vendor\faye-websocket.js.

CryptoES is a cryptography algorithms library compatible with ES6 and TypeScript. Prior to version 2.1.0, CryptoES PBKDF2 is 1,000 times weaker than originally specified in 1993, and at least 1,300,000 times weaker than current industry standard. This is because it both defaults to SHA1, a cryptographic hash algorithm considered insecure since at least 2005, and defaults to one single iteration, a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to preimage and collision attacks. If used to protect passwords, the impact is high. If used to generate signatures, the impact is high. Version 2.1.0 contains a patch for this issue. As a workaround, configure CryptoES to use SHA256 with at least 250,000 iterations.

Out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 (and potentially earlier unsupported versions) that are configured to use the non-default Blowfish cryptography algorithm use a hardcoded key. An attacker with access to network traffic and to this key could decrypt network traffic between the Control-M/Agent and Server.

Use of a Broken or Risky Cryptographic Algorithm in GitHub repository gnuboard/gnuboard5 prior to and including 5.5.5. A vulnerability in gnuboard v5.5.5 and below uses weak encryption algorithms leading to sensitive information exposure. This allows an attacker to derive the email address of any user, including when the 'Let others see my information.' box is ticked off. Or to send emails to any email address, with full control of its contents

An issue in the index.js decryptCookie function of cookie-encrypter v1.0.1 allows attackers to execute a bit flipping attack.

A service supports the use of a deprecated and unsafe TLS version. This could be exploited to expose sensitive information, modify data in unexpected ways or spoof identities of other users or devices, affecting the confidentiality and integrity of the device.

The SSL/TLS configuration of Fresenius Kabi Agilia Link + version 3.0 has serious deficiencies that may allow an attacker to compromise SSL/TLS sessions in different ways. An attacker may be able to eavesdrop on transferred data, manipulate data allegedly secured by SSL/TLS, and impersonate an entity to gain access to sensitive information.

An issue discovered in the RunHTTPServer function in Gorush v1.18.4 allows attackers to intercept and manipulate data due to use of deprecated TLS version.

ntpkeygen can generate keys that ntpd fails to parse. NTPsec 1.2.0 allows ntpkeygen to generate keys with '#' characters. ntpd then either pads, shortens the key, or fails to load these keys entirely, depending on the key type and the placement of the '#'. This results in the administrator not being able to use the keys as expected or the keys are shorter than expected and easier to brute-force, possibly resulting in MITM attacks between ntp clients and ntp servers. For short AES128 keys, ntpd generates a warning that it is padding them.

crypto-js is a JavaScript library of crypto standards. Prior to version 4.2.0, crypto-js PBKDF2 is 1,000 times weaker than originally specified in 1993, and at least 1,300,000 times weaker than current industry standard. This is because it both defaults to SHA1, a cryptographic hash algorithm considered insecure since at least 2005, and defaults to one single iteration, a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to preimage and collision attacks. If used to protect passwords, the impact is high. If used to generate signatures, the impact is high. Version 4.2.0 contains a patch for this issue. As a workaround, configure crypto-js to use SHA256 with at least 250,000 iterations.

Rocket-Chip commit 4f8114374d8824dfdec03f576a8cd68bebce4e56 was discovered to contain insufficient cryptography via the component /rocket/RocketCore.scala.

A ZTE product is impacted by the cryptographic issues vulnerability. The encryption algorithm is not properly used, so remote attackers could use this vulnerability for account credential enumeration attack or brute-force attack for password guessing. This affects: ZXIPTV, ZXIPTV-WEB-PV5.09.08.04.

SanDisk PrivateAccess versions prior to 6.4.9 support insecure TLS 1.0 and TLS 1.1 protocols which are susceptible to man-in-the-middle attacks thereby compromising confidentiality and integrity of data.

A use of a weak cryptographic algorithm vulnerability [CWE-327] in FortiNAC 9.4.1 and below, 9.2.6 and below, 9.1.0 all versions, 8.8.0 all versions, 8.7.0 all versions may increase the chances of an attacker to have access to sensitive information or to perform man-in-the-middle attacks.

A vulnerability in Cisco HyperFlex Software could allow an unauthenticated, remote attacker to perform a man-in-the-middle attack. The vulnerability is due to insufficient key management. An attacker could exploit this vulnerability by obtaining a specific encryption key for the cluster. A successful exploit could allow the attacker to perform a man-in-the-middle attack against other nodes in the cluster.

A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions < V2.16.0), RUGGEDCOM ROX MX5000RE (All versions < V2.16.0), RUGGEDCOM ROX RX1400 (All versions < V2.16.0), RUGGEDCOM ROX RX1500 (All versions < V2.16.0), RUGGEDCOM ROX RX1501 (All versions < V2.16.0), RUGGEDCOM ROX RX1510 (All versions < V2.16.0), RUGGEDCOM ROX RX1511 (All versions < V2.16.0), RUGGEDCOM ROX RX1512 (All versions < V2.16.0), RUGGEDCOM ROX RX1524 (All versions < V2.16.0), RUGGEDCOM ROX RX1536 (All versions < V2.16.0), RUGGEDCOM ROX RX5000 (All versions < V2.16.0). The webserver of the affected devices support insecure TLS 1.0 protocol. An attacker could achieve a man-in-the-middle attack and compromise confidentiality and integrity of data.

An unauthenticated remote attacker could exploit the used, insecure TLS 1.0 and TLS 1.1 protocols to intercept and manipulate encrypted communications between the Com-Server and connected systems.