In several JetBrains IntelliJ IDEA versions, creating remote run configurations of JavaEE application servers leads to saving a cleartext record of the server credentials in the IDE configuration files. The issue has been fixed in the following versions: 2018.3.5, 2018.2.8, 2018.1.8.

In JetBrains TeamCity before 2021.2.3, environment variables of the "password" type could be logged in some cases.

In JetBrains Hub before 2021.1.13890, integration with JetBrains Account exposed an API key with excessive permissions.

In JetBrains YouTrack before 2020.3.7955, an attacker could access workflow rules without appropriate access grants.

In JetBrains TeamCity before 2019.2.3, password parameters could be disclosed via build logs.

In JetBrains YouTrack before 2020.2.8527, the subtasks workflow could disclose issue existence.

In JetBrains Kotlin before 1.4.21, a vulnerable Java API was used for temporary file and folder creation. An attacker was able to read data from such files and list directories due to insecure permissions.

In JetBrains YouTrack before 2020.3.6638, improper access control for some subresources leads to information disclosure via the REST API.

In JetBrains PyCharm 2019.2.5 and 2019.3 on Windows, Apple Notarization Service credentials were included. This is fixed in 2019.2.6 and 2019.3.3.

In JetBrains TeamCity before 2019.2.2, password values were shown in an unmasked format on several pages.

In JetBrains TeamCity before 2023.05 a specific endpoint was vulnerable to brute force attacks

In JetBrains YouTrack Mobile before 2021.2, the client-side cache on iOS could contain sensitive information.

In JetBrains TeamCity before 2021.1, passwords in cleartext sometimes could be stored in VCS.

In JetBrains WebStorm before 2021.1, HTTP requests were used instead of HTTPS.

In JetBrains TeamCity before 2020.2.3, insufficient checks of the redirect_uri were made during GitHub SSO token exchange.

In JetBrains TeamCity before 2020.2, an ECR token could be exposed in a build's parameters.

In JetBrains YouTrack before 2020.6.1767, an issue's existence could be disclosed via YouTrack command execution.

In JetBrains IntelliJ IDEA before 2020.2, HTTP links were used for several remote repositories instead of HTTPS.

JetBrains YouTrack before 2020.2.8873 is vulnerable to SSRF in the Workflow component.

In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.

In JetBrains Rider versions 2019.3 EAP2 through 2019.3 EAP7, there were unsigned binaries provided by the Windows installer. This issue was fixed in release version 2019.3.

In JetBrains GoLand before 2019.3.2, the plugin repository was accessed via HTTP instead of HTTPS.

In JetBrains YouTrack before 2019.2.59309, SMTP/Jabber settings could be accessed using backups.

In JetBrains TeamCity before 2019.1.5, some server-stored passwords could be shown via the web UI.

The Bitcoin Proof-of-Work algorithm does not consider a certain attack methodology related to 80-byte block headers with a variety of initial 64-byte chunks followed by the same 16-byte chunk, multiple candidate root values ending with the same 4 bytes, and calculations involving sqrt numbers. This violates the security assumptions of (1) the choice of input, outside of the dedicated nonce area, fed into the Proof-of-Work function should not change its difficulty to evaluate and (2) every Proof-of-Work function execution should be independent. NOTE: a number of persons feel that this methodology is a benign mining optimization, not a vulnerability

In NetBSD through 9.2, the IPv6 Flow Label generation algorithm employs a weak cryptographic PRNG.

Zulip is an open-source team collaboration tool. Zulip Server installs RabbitMQ for internal message passing. In versions of Zulip Server prior to 4.9, the initial installation (until first reboot, or restart of RabbitMQ) does not successfully limit the default ports which RabbitMQ opens; this includes port 25672, the RabbitMQ distribution port, which is used as a management port. RabbitMQ's default "cookie" which protects this port is generated using a weak PRNG, which limits the entropy of the password to at most 36 bits; in practicality, the seed for the randomizer is biased, resulting in approximately 20 bits of entropy. If other firewalls (at the OS or network level) do not protect port 25672, a remote attacker can brute-force the 20 bits of entropy in the "cookie" and leverage it for arbitrary execution of code as the rabbitmq user. They can also read all data which is sent through RabbitMQ, which includes all message traffic sent by users. Version 4.9 contains a patch for this vulnerability. As a workaround, ensure that firewalls prevent access to ports 5672 and 25672 from outside the Zulip server.

In NetBSD through 9.2, the IPv6 fragment ID generation algorithm employs a weak cryptographic PRNG.

react-native-meteor-oauth is a library for Oauth2 login to a Meteor server in React Native. The oauth Random Token is generated using a non-cryptographically strong RNG (Math.random()).

Eclipse TinyDTLS through 0.9-rc1 relies on the rand function in the C library, which makes it easier for remote attackers to compute the master key and then decrypt DTLS traffic.

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.

Mateso PasswordSafe through 8.13.9.26689 has Weak Cryptography.

A use of a cryptographically weak pseudo-random number generator vulnerability in the authenticator of the Identity Based Encryption service of FortiMail 6.4.0 through 6.4.4, and 6.2.0 through 6.2.7 may allow an unauthenticated attacker to infer parts of users authentication tokens and reset their credentials.

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.

An issue was discovered in Joomla! 3.2.0 through 3.9.24. Usage of the insecure rand() function within the process of generating the 2FA secret.

The cryptocurrency wallet entropy seeding mechanism used in Libbitcoin Explorer 3.0.0 through 3.6.0 is weak, aka the Milk Sad issue. The use of an mt19937 Mersenne Twister PRNG restricts the internal entropy to 32 bits regardless of settings. This allows remote attackers to recover any wallet private keys generated from "bx seed" entropy output and steal funds. (Affected users need to move funds to a secure new cryptocurrency wallet.) NOTE: the vendor's position is that there was sufficient documentation advising against "bx seed" but others disagree. NOTE: this was exploited in the wild in June and July 2023.

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.

Landscape cryptographic keys were insecurely generated with a weak pseudo-random generator.

Nextcloud server is an open source home cloud implementation. In affected versions the generated fallback password when creating a share was using a weak complexity random number generator, so when the sharer did not change it the password could be guessable to an attacker willing to brute force it. It is recommended that the Nextcloud Server is upgraded to 24.0.10 or 25.0.4. This issue only affects users who do not have a password policy enabled, so enabling a password policy is an effective mitigation for users unable to upgrade.

The Crypt::Random::Source package before 0.13 for Perl has a fallback to the built-in rand() function, which is not a secure source of random bits.

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.

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.

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).

An issue was discovered in Rclone before 1.53.3. Due to the use of a weak random number generator, the password generator has been producing weak passwords with much less entropy than advertised. The suggested passwords depend deterministically on the time the second rclone was started. This limits the entropy of the passwords enormously. These passwords are often used in the crypt backend for encryption of data. It would be possible to make a dictionary of all possible passwords with about 38 million entries per password length. This would make decryption of secret material possible with a plausible amount of effort. NOTE: all passwords generated by affected versions should be changed.

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.

OpenVPN Access Server before 2.11 uses a weak random generator used to create user session token for the web portal

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.