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
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
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 Dat
Smolder versions through 1.51 for Perl uses insecure rand() function for cryptographic functions.
Smolder 1.51 and earlier for Perl uses the rand() function as the default source of entropy, which is
An insufficient entropy vulnerability was found in glibc. The getrandom and arc4random family of functions may return predictable randomness if these functions are called again after the fork, which h
coturn is a free open source implementation of TURN and STUN Server. Versions 4.6.2r5 through 4.7.0-r4 have a bad random number generator for nonces and port randomization after refactoring. Additiona
An issue was discovered in Mbed TLS before 3.6.6 and 4.x before 4.1.0 and TF-PSA-Crypto before 1.1.0. There is a Predictable Seed in a Pseudo-Random Number Generator (PRNG).
Crypt::SysRandom::XS versions before 0.010 for Perl is vulnerable to a heap buffer overflow in the XS function random_bytes().
The function does not validate that the length parameter is non-negative
** UNSUPPORTED WHEN ASSIGNED ** Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG) vulnerability in Apache Cocoon.
This issue affects Apache Cocoon: all versions.
When a continuation
Crypt::CBC versions between 1.21 and 3.05 for Perl may use the rand() function as the default source of entropy, which is not cryptographically secure, for cryptographic functions.
This issue affects
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::R
An integer overflow vulnerability existed in the static function wolfssl_add_to_chain, that caused heap corruption when certificate data was written out of bounds of an insufficiently sized certificat
Crypt::ScryptKDF versions through 0.010 for Perl uses insecure random number source when no CSPRNG module is available.
The random_bytes function fell back to using the built-in rand() function when
Apache::API::Password versions through 0.5.2 for Perl can generate insecure random values for salts.
The _make_salt and _make_salt_bcrypt methods will attept to load Crypt::URandom and then Bytes::Ra
Crypt::SaltedHash versions through 0.09 for Perl generate insecure random values for salts.
These versions use the built-in rand function, which is predictable and unsuitable for cryptography.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: use get_random_u32 instead of prandom
bh might occur while updating per-cpu rnd_state from user context,
ie. local_out
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 Entro
rust-openssl provides OpenSSL bindings for the Rust programming language. From 0.9.24 to before 0.10.78, the FFI trampolines behind SslContextBuilder::set_psk_client_callback, set_psk_server_callback
WWW::OAuth 1.000 and earlier for Perl uses the rand() function as the default source of entropy, which is not cryptographically secure, for cryptographic functions.
A heap-buffer-overflow vulnerability exists in wolfSSL's wolfSSL_d2i_SSL_SESSION() function. When deserializing session data with SESSION_CERTS enabled, certificate and session id lengths are read fro
Page 1+ Next →