The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.

Primary

Architecture and Design

Implementation
REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Medium

Availability
DoS: Crash, Exit, or Restart
If a pseudo-random number generator is using a limited entropy source which runs out (if the generator fails closed), the program may pause or crash.

Access Control
Other
Bypass Protection Mechanism
Other
If a PRNG is using a limited entropy source which runs out, and the generator fails open, the generator could produce predictable random numbers. Potentially a weak source of random numbers could weaken the encryption method used for authentication of users.

Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Architecture and Design
Requirements
Libraries or Frameworks
Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").

Implementation
Consider a PRNG that re-seeds itself as needed from high-quality pseudo-random output, such as hardware devices.

Architecture and Design
When deciding which PRNG to use, look at its sources of entropy. Depending on what your security needs are, you may need to use a random number generator that always uses strong random data -- i.e., a random number generator that attempts to be strong but will fail in a weak way or will always provide some middle ground of protection through techniques like re-seeding. Generally, something that always provides a predictable amount of strength is preferable.

[REF-1374]
Chain: JavaScript-based cryptocurrency library can fall back to the insecure Math.random() function instead of reporting a failure (CWE-392), thus reducing the entropy (CWE-332) and leading to generation of non-unique cryptographic keys for Bitcoin wallets (CWE-1391)
https://www.unciphered.com/blog/randstorm-you-cant-patch-a-house-of-cards

CVE-2019-1715
security product has insufficient entropy in the DRBG, allowing collisions and private key discovery
https://www.cve.org/CVERecord?id=CVE-2019-1715

Insufficient entropy in PRNG

MSC02-J
Generate strong random numbers

Allowed
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

As of CWE 4.5, terminology related to randomness, entropy, and
predictability can vary widely. Within the developer and other
communities, "randomness" is used heavily. However, within
cryptography, "entropy" is distinct, typically implied as a
measurement. There are no commonly-used definitions, even within
standards documents and cryptography papers. Future versions of
CWE will attempt to define these terms and, if necessary,
distinguish between them in ways that are appropriate for
different communities but do not reduce the usability of CWE for
mapping, understanding, or other scenarios.

CLASP
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Common_Consequences, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2009-03-10
updated Potential_Mitigations

CWE Content Team
MITRE
2009-12-28
updated Potential_Mitigations

CWE Content Team
MITRE
2010-06-21
updated Potential_Mitigations

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2011-09-13
updated Potential_Mitigations, References

CWE Content Team
MITRE
2012-05-11
updated Common_Consequences, Demonstrative_Examples, Relationships

CWE Content Team
MITRE
2015-12-07
updated Relationships

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships

CWE Content Team
MITRE
2019-01-03
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2019-06-20
updated Relationships

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2021-03-15
updated References

CWE Content Team
MITRE
2021-07-20
updated Maintenance_Notes

CWE Content Team
MITRE
2021-10-28
updated Observed_Examples

CWE Content Team
MITRE
2023-04-27
updated References, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Observed_Examples, References

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated References

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Detection_Factors, Relationships, Weakness_Ordinalities