| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| WBCE CMS is a content management system. Versions 1.6.4 and below use function GenerateRandomPassword() to create passwords using PHP's rand(). rand() is not cryptographically secure, which allows password sequences to be predicted or brute-forced. This can lead to user account compromise or privilege escalation if these passwords are used for new accounts or password resets. The vulnerability is fixed in version 1.6.5. |
| Apache Druid’s Kerberos authenticator uses a weak fallback secret when the `druid.auth.authenticator.kerberos.cookieSignatureSecret` configuration is not explicitly set. In this case, the secret is generated using `ThreadLocalRandom`,
which is not a crypto-graphically secure random number generator. This
may allow an attacker to predict or brute force the secret used to sign
authentication cookies, potentially enabling token forgery or
authentication bypass. Additionally, each process generates its own
fallback secret, resulting in inconsistent secrets across nodes. This
causes authentication failures in distributed or multi-broker
deployments, effectively leading to a incorrectly configured clusters. Users are
advised to configure a strong `druid.auth.authenticator.kerberos.cookieSignatureSecret`
This issue affects Apache Druid: through 34.0.0.
Users are recommended to upgrade to version 35.0.0, which fixes the issue making it mandatory to set `druid.auth.authenticator.kerberos.cookieSignatureSecret` when using the Kerberos authenticator. Services will fail to come up if the secret is not set. |
| In the OpenSSL compatibility layer implementation, the function RAND_poll() was not behaving as expected and leading to the potential for predictable values returned from RAND_bytes() after fork() is called. This can lead to weak or predictable random numbers generated in applications that are both using RAND_bytes() and doing fork() operations. This only affects applications explicitly calling RAND_bytes() after fork() and does not affect any internal TLS operations. Although RAND_bytes() documentation in OpenSSL calls out not being safe for use with fork() without first calling RAND_poll(), an additional code change was also made in wolfSSL to make RAND_bytes() behave similar to OpenSSL after a fork() call without calling RAND_poll(). Now the Hash-DRBG used gets reseeded after detecting running in a new process. If making use of RAND_bytes() and calling fork() we recommend updating to the latest version of wolfSSL. Thanks to Per Allansson from Appgate for the report. |
| Web::API 2.8 and earlier for Perl uses the rand() function as the default source of entropy, which is not cryptographically secure, for cryptographic functions.
Specifically Web::API uses the Data::Random library which specifically states that it is "Useful mostly for test programs". Data::Random uses the rand() function. |
| WebService::Xero 0.11 and earlier for Perl uses the rand() function as the default source of entropy, which is not cryptographically secure, for cryptographic functions.
Specifically WebService::Xero uses the Data::Random library which specifically states that it is "Useful mostly for test programs". Data::Random uses the rand() function. |
| In PuTTY 0.68 through 0.80 before 0.81, biased ECDSA nonce generation allows an attacker to recover a user's NIST P-521 secret key via a quick attack in approximately 60 signatures. This is especially important in a scenario where an adversary is able to read messages signed by PuTTY or Pageant. The required set of signed messages may be publicly readable because they are stored in a public Git service that supports use of SSH for commit signing, and the signatures were made by Pageant through an agent-forwarding mechanism. In other words, an adversary may already have enough signature information to compromise a victim's private key, even if there is no further use of vulnerable PuTTY versions. After a key compromise, an adversary may be able to conduct supply-chain attacks on software maintained in Git. A second, independent scenario is that the adversary is an operator of an SSH server to which the victim authenticates (for remote login or file copy), even though this server is not fully trusted by the victim, and the victim uses the same private key for SSH connections to other services operated by other entities. Here, the rogue server operator (who would otherwise have no way to determine the victim's private key) can derive the victim's private key, and then use it for unauthorized access to those other services. If the other services include Git services, then again it may be possible to conduct supply-chain attacks on software maintained in Git. This also affects, for example, FileZilla before 3.67.0, WinSCP before 6.3.3, TortoiseGit before 2.15.0.1, and TortoiseSVN through 1.14.6. |
| RT-Thread through 5.0.2 generates random numbers with a weak algorithm of "seed = 214013L * seed + 2531011L; return (seed >> 16) & 0x7FFF;" in calc_random in drivers/misc/rt_random.c. |
| EDK2's Network Package is susceptible to a predictable TCP Initial Sequence Number. This
vulnerability can be exploited by an attacker to gain unauthorized
access and potentially lead to a loss of Confidentiality. |
| EDK2's Network Package is susceptible to a predictable TCP Initial Sequence Number. This
vulnerability can be exploited by an attacker to gain unauthorized
access and potentially lead to a loss of Confidentiality. |
| EDK2's Network Package is susceptible to an out-of-bounds read
vulnerability when processing the IA_NA or IA_TA option in a DHCPv6 Advertise message. This
vulnerability can be exploited by an attacker to gain unauthorized
access and potentially lead to a loss of Confidentiality. |
| Use of cryptographically weak pseudo-random number generator (PRNG) vulnerability in the SonicWall SMA100 SSLVPN backup code generator that, in certain cases, can be predicted by an attacker, potentially exposing the generated secret. |
| Mojolicious versions from 7.28 for Perl will generate weak HMAC session cookie secrets via "mojo generate app" by default
When creating a default app skeleton with the "mojo generate app" tool, a weak secret is written to the application's configuration file using the insecure rand() function, and used for authenticating and protecting the integrity of the application's sessions. This may allow an attacker to brute force the application's session keys. |
| Formidable (aka node-formidable) 2.1.0 through 3.x before 3.5.3 relies on hexoid to prevent guessing of filenames for untrusted executable content; however, hexoid is documented as not "cryptographically secure." (Also, there is a scenario in which only the last two characters of a hexoid string need to be guessed, but this is not often relevant.) NOTE: this does not imply that, in a typical use case, attackers will be able to exploit any hexoid behavior to upload and execute their own content. |
| A vulnerability in langgenius/dify v0.10.1 allows an attacker to take over any account, including administrator accounts, by exploiting a weak pseudo-random number generator (PRNG) used for generating password reset codes. The application uses `random.randint` for this purpose, which is not suitable for cryptographic use and can be cracked. An attacker with access to workflow tools can extract the PRNG output and predict future password reset codes, leading to a complete compromise of the application. |
| OleumTech WIO DH2 Wireless Gateway and Sensor Wireless I/O Modules rely exclusively on a time value for entropy in key generation, which makes it easier for remote attackers to defeat cryptographic protection mechanisms by predicting the time of project creation. |
| Crypt::Random Perl package 1.05 through 1.55 may use rand() function, which is not cryptographically strong, for cryptographic functions.
If the Provider is not specified and /dev/urandom or an Entropy Gathering Daemon (egd) service is not available Crypt::Random will default to use the insecure Crypt::Random::rand provider.
In particular, Windows versions of perl will encounter this issue by default. |
| Net::Dropbox::API 1.9 and earlier for Perl uses the rand() function as the default source of entropy, which is not cryptographically secure, for cryptographic functions.
Specifically Net::Dropbox::API uses the Data::Random library which specifically states that it is "Useful mostly for test programs". Data::Random uses the rand() function. |
| DBIx::Class::EncodedColumn use the rand() function, which is not cryptographically secure to salt password hashes.
This vulnerability is associated with program files lib/DBIx/Class/EncodedColumn/Digest.pm.
This issue affects DBIx::Class::EncodedColumn until 0.00032. |
| Data::Entropy for Perl 0.007 and earlier use the rand() function as the default source of entropy, which is not cryptographically secure, for cryptographic functions. |
| Net::Xero 0.044 and earlier for Perl uses the rand() function as the default source of entropy, which is not cryptographically secure, for cryptographic functions.
Specifically Net::Xero uses the Data::Random library which specifically states that it is "Useful mostly for test programs". Data::Random uses the rand() function. |
