CWE-339, Small Seed Space in PRNG, is when a pseudo-random number generator uses a relatively small seed space. That makes it open to brute force.
Any code that builds passwords, tokens or keys from a generator seeded with a small value is affected, including code that does so indirectly through a utility library.
How it happens
MITRE explains that PRNGs are entirely deterministic once seeded, so guessing the seed should be extremely difficult. If an attacker collects outputs and tries every possible seed until one matches, the attacker then knows the output of every later call. A small seed space means far fewer possibilities to exhaust.
// Vulnerable: java.util.Random has a 48-bit internal seed
Random r = new Random();
String pw = RandomStringUtils.random(12, 0, 0, true, true, null, r);
The observed example is CVE-2019-10908: a product generated passwords through org.apache.commons.lang.RandomStringUtils, which uses java.util.Random internally. The weakness sat inside a helper that looked harmless.
What an attacker gains
The record lists impact as varying by context. For passwords and tokens, it means predicting values the system trusts.
How to find it
The record lists no specific detection method. Trace the source of randomness behind every generated password or token, including library helpers, and check whether it is a cryptographic generator.
How to fix it
- Use well vetted pseudo-random algorithms with adequate length seeds. MITRE gives 256 bits as a good starting point for "random enough" output.
- Use modules that conform to FIPS 140-2, or the more recent FIPS 140-3 if possible.
- Replace helpers that wrap a weak generator with ones that accept a secure source.
SecureRandom sr = new SecureRandom();
String pw = RandomStringUtils.random(12, 0, 0, true, true, null, sr);
Quick check
Why does a small seed matter if outputs look random?
Because the whole sequence is determined by the seed. Fewer seeds means fewer sequences to test.
