CWE-1241 covers a device that produces random numbers with a predictable algorithm. Anything that relies on those numbers for secrecy, such as keys, nonces and session tokens, inherits the predictability. The MITRE entry is framed around hardware and system on chip designs, but its observed example is a PHP framework, so the same mistake shows up in plain application code.
How it happens
A pseudo-random number generator has a finite number of internal states. That means it eventually repeats. Its output can also expose its internal state to reverse engineering or tampering.
Three cases from MITRE show how teams end up here.
Space constraints. A designer needs a random value for a cryptographic function. A cryptographically secure generator takes too much area, so a linear feedback shift register (LFSR) goes in instead. It produces numbers that look random but have too little entropy for encryption.
A buggy SoC from a contest. MITRE cites the pseudo-random generator in a deliberately flawed SoC from the HACK@DAC'21 competition. It uses an LFSR whose next input bit comes from a linear function of earlier states. Given a long enough cycle, the output enters a repeating pattern, and a repeating pattern is predictable.
Application code. CVE-2021-3692 is listed as an example where a PHP framework used mt_rand(), a Mersenne Twister function, to generate tokens. See the Gold page for CVE-2021-3692.
What an attacker gains
MITRE lists confidentiality, specifically reading application data, with high impact. If an attacker can predict the next value, they can predict a key or a token. That means decrypting traffic or guessing tokens that were supposed to be secret.
How to find it
The record has no detection methods for this weakness. These are practical checks based on the description.
- Search code for general purpose random functions used in a security context. In PHP, look for
mt_rand,randanduniqidnear token or key generation. - In hardware designs, look for LFSRs or similar shift register logic feeding a cryptographic block.
- Ask where every key, nonce, salt and token comes from, and write down the answer.
A quick grep helps:
grep -rnE "mt_rand|\brand\(|uniqid\(" --include="*.php" .
How to fix it
MITRE recommends using a true random number generator (TRNG) to secure encryption schemes. Hardware TRNGs use physical phenomena such as electrical noise, which gives numbers that are unpredictable, unbiased and independent. The advice applies at the architecture stage and again at implementation.
In application code the equivalent is the operating system's cryptographically secure source.
// Vulnerable: Mersenne Twister is not meant for secrets
$token = bin2hex(pack('N', mt_rand()));
// Fix: cryptographically secure bytes from the OS
$token = bin2hex(random_bytes(32));
If a design cannot afford a proper random source, treat that as a design problem to resolve. The LFSR shortcut in MITRE's example is exactly how this weakness gets built in.
Try it yourself
A static scan is a good way to catch weak random calls near token code. This demo walks through a code scan.
Click through it at your own pace, or open it full screen.
Quick check
Why is an LFSR a poor source for cryptographic keys?
Its next bit is a linear function of earlier states, so the output falls into a repeating, predictable cycle and has too little entropy for encryption.
What does MITRE recommend instead?
A true random number generator, which uses physical phenomena such as electrical noise to produce unpredictable, unbiased and independent numbers.
