The product's random number generator produces a series of values which, when observed, can be used to infer a relatively small range of possibilities for the next value that could be generated.
The output of a random number generator should not be predictable based on observations of previous values. In some cases, an attacker cannot predict the exact value that will be produced next, but can narrow down the possibilities significantly. This reduces the amount of effort to perform a brute force attack. For example, suppose the product generates random numbers between 1 and 100, but it always produces a larger value until it reaches 100. If the generator produces an 80, then the attacker knows that the next value will be somewhere between 81 and 100. Instead of 100 possibilities, the attacker only needs to consider 20.

Primary

Architecture and Design

Implementation

Other
Varies by Context

Increase the entropy used to seed a PRNG.

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
Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block.

Predictable Value Range from Previous Values

Allowed
This CWE entry is at the Base 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.

PLOVER
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 Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2008-10-14
updated Description

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

CWE Content Team
MITRE
2011-06-27
updated Common_Consequences

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

CWE Content Team
MITRE
2012-05-11
updated References, Relationships

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

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

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2021-07-20
updated Maintenance_Notes

CWE Content Team
MITRE
2023-01-31
updated Description

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

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

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 Weakness_Ordinalities