An issue was discovered in Matrix Sydent before 1.0.3 and Synapse before 0.99.3.1. Random number generation is mishandled, which makes it easier for attackers to predict a Sydent authentication token or a Synapse random ID.

Ratpack versions before 1.6.1 generate a session ID using a cryptographically weak PRNG in the JDK's ThreadLocalRandom. This means that if an attacker can determine a small window for the server start time and obtain a session ID value, they can theoretically determine the sequence of session IDs.

The SAML identifier generated within SAML2Utils.java was found to make use of the apache commons-lang3 RandomStringUtils class which makes them predictable due to RandomStringUtils PRNG's algorithm not being cryptographically strong. This issue only affects the 3.X release of pac4j-saml.

Multiple classes used within Apereo CAS before release 6.1.0-RC5 makes use of apache commons-lang3 RandomStringUtils for token and ID generation which makes them predictable due to RandomStringUtils PRNG's algorithm not being cryptographically strong.

In Snapdragon (Automobile, Mobile, Wear) in version MDM9206, MDM9607, MDM9640, MDM9650, MSM8996AU, QCA6574AU, SD 210/SD 212/SD 205, SD 425, SD 427, SD 430, SD 435, SD 450, SD 615/16/SD 415, SD 625, SD 650/52, SD 820A, SD 835, SD 845, SD 850, SDA660, SDM429, SDM439, SDM630, SDM632, SDM636, SDM660, SDM710, Snapdragon_High_Med_2016, MAC address randomization performed during probe requests (for privacy reasons) is not done properly due to a flawed RNG which produces repeating output much earlier than expected.

In Snapdragon (Automobile, Mobile, Wear) in version IPQ8074, MDM9206, MDM9607, MDM9640, MDM9650, MSM8996AU, QCA6574AU, SD 210/SD 212/SD 205, SD 425, SD 427, SD 430, SD 435, SD 450, SD 625, SD 820A, SD 835, SD 845, SD 850, SDA660, SDM429, SDM439, SDM630, SDM632, SDM636, SDM660, SDM710, Snapdragon_High_Med_2016, MAC address randomization performed during probe requests is not done properly due to a flawed RNG which produced repeating output much earlier than expected.

A gambling smart contract implementation for RuletkaIo, an Ethereum gambling game, generates a random value that is predictable by an external contract call. The developer wrote a random() function that uses a block timestamp and block hash from the Ethereum blockchain. This can be predicted by writing the same random function code in an exploit contract to determine the deadSeat value.

A lottery smart contract implementation for Greedy 599, an Ethereum gambling game, generates a random value that is predictable via an external contract call. The developer used the extcodesize() function to prevent a malicious contract from being called, but the attacker can bypass it by writing the core code in the constructor of their exploit code. Therefore, it allows attackers to always win and get rewards.

The fallback function of a simple lottery smart contract implementation for Lucky9io, an Ethereum gambling game, generates a random value with the publicly readable variable entry_number. This variable is private, yet it is readable by eth.getStorageAt function. Also, attackers can purchase a ticket at a low price by directly calling the fallback function with small msg.value, because the developer set the currency unit incorrectly. Therefore, it allows attackers to always win and get rewards.

Lightbend Akka 2.5.x before 2.5.16 allows message disclosure and modification because of an RNG error. A random number generator is used in Akka Remoting for TLS (both classic and Artery Remoting). Akka allows configuration of custom random number generators. For historical reasons, Akka included the AES128CounterSecureRNG and AES256CounterSecureRNG random number generators. The implementations had a bug that caused the generated numbers to be repeated after only a few bytes. The custom RNG implementations were not configured by default but examples in the documentation showed (and therefore implicitly recommended) using the custom ones. This can be used by an attacker to compromise the communication if these random number generators are enabled in configuration. It would be possible to eavesdrop, replay, or modify the messages sent with Akka Remoting/Cluster.

CredHub Service Broker uses guessable client secret

Pivotal CredHub Service Broker, versions prior to 1.1.0, uses a guessable form of random number generation in creating service broker's UAA client. A remote malicious user may guess the client secret and obtain or modify credentials for users of the CredHub Service.

The "PayWinner" function of a simplelottery smart contract implementation for The Ethereum Lottery, an Ethereum gambling game, generates a random value with publicly readable variable "maxTickets" (which is private, yet predictable and readable by the eth.getStorageAt function). Therefore, it allows attackers to always win and get rewards.

The endCoinFlip function and throwSlammer function of the smart contract implementations for Cryptogs, an Ethereum game, generate random numbers with an old block's hash. Therefore, attackers can predict the random number and always win the game.

The random() function of the smart contract implementation for CryptoSaga, an Ethereum game, generates a random value with publicly readable variables such as timestamp, the current block's blockhash, and a private variable (which can be read with a getStorageAt call). Therefore, attackers can precompute the random number and manipulate the game (e.g., get powerful characters or get critical damages).

The randMod() function of the smart contract implementation for MyCryptoChamp, an Ethereum game, generates a random value with publicly readable variables such as the current block information and a private variable, (which can be read with a getStorageAt call). Therefore, attackers can get powerful champs/items and get rewards.

The _addguess function of a simplelottery smart contract implementation for 1000 Guess, an Ethereum gambling game, generates a random value with publicly readable variables such as the current block information and a private variable (which can be read with a getStorageAt call). Therefore, it allows attackers to always win and get rewards.

The maxRandom function of a smart contract implementation for All For One, an Ethereum gambling game, generates a random value with publicly readable variables because the _seed value can be retrieved with a getStorageAt call. Therefore, it allows attackers to always win and get rewards.

In Snapdragon (Automobile, Mobile, Wear) in version IPQ8074, MDM9206, MDM9607, MDM9640, MDM9650, MSM8996AU, QCA4531, QCA6174A, QCA6564, QCA6574, QCA6574AU, QCA6584, QCA6584AU, QCA9377, QCA9378, QCA9379, SD 425, SD 427, SD 430, SD 435, SD 450, SD 600, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835, SD 845, SD 850, SDM630, SDM632, SDM636, SDM660, SDX20, Snapdragon_High_Med_2016, cryptographic issues due to the random number generator was not a strong one in NAN.

In Snapdragon (Automobile, Mobile, Wear) in version MDM9206, MDM9607, MDM9640, MDM9650, MSM8996AU, QCA6574AU, QCA6584, SD 210/SD 212/SD 205, SD 425, SD 427, SD 430, SD 435, SD 450, SD 625, SD 650/52, SD 820A, SD 845, SDM429, SDM439, SDM630, SDM632, SDM636, SDM660, SDX20, Snapdragon_High_Med_2016, MAC address randomization performed during probe requests is not done properly due to a flawed RNG in use.

It was discovered that QtPass before 1.2.1, when using the built-in password generator, generates possibly predictable and enumerable passwords. This only applies to the QtPass GUI.