CWE-336, Same Seed in PRNG, is when a pseudo-random number generator uses the same seed every time the product is initialized.
Developers who hard-code a seed for reproducible tests, then ship it, are the usual cause.
How it happens
PRNGs are deterministic. MITRE notes that the same seed on each initialization produces the same output in the same order. If an attacker guesses or knows the seed, the attacker may determine the numbers that will be produced.
// Vulnerable: fixed seed shipped to production
const rng = new SeededRandom(12345);
const token = rng.next();
The observed example, CVE-2022-39218, is an SDK for a JavaScript serverless app builder that used the same fixed seed for a PRNG, allowing cryptography bypass.
What an attacker gains
The record lists bypassing protection mechanisms and access control: whatever relied on the unpredictable output can be defeated.
How to find it
Static analysis can flag seed calls with literals. Search for the word seed in code and check each one. Restart a test instance twice and compare generated values.
How to fix it
MITRE says not to reuse PRNG seeds, and to consider a generator that periodically re-seeds itself from high quality output such as hardware devices. Use modules that conform to FIPS 140-2, or the newer FIPS 140-3 where possible. Keep fixed seeds in test code only and fail builds if they appear in production paths.
Quick check
Is a fixed seed ever acceptable?
For tests that need repeatable output, yes. Never for tokens, keys or passwords.
