The product uses a cryptographic primitive that uses an Initialization
Vector (IV), but the product does not generate IVs that are
sufficiently unpredictable or unique according to the expected
cryptographic requirements for that primitive.

By design, some cryptographic primitives
(such as block ciphers) require that IVs
must have certain properties for the
uniqueness and/or unpredictability of an
IV. Primitives may vary in how important
these properties are. If these properties
are not maintained, e.g. by a bug in the
code, then the cryptography may be weakened
or broken by attacking the IVs themselves.

Primary

Resultant

Implementation

Confidentiality
Read Application Data
If the IV is not properly initialized, data that is encrypted can be compromised and information about the data can be leaked. See [REF-1179].

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.)
High

Implementation
Different cipher
modes have different requirements for
their IVs. When choosing and implementing
a mode, it is important to understand
those requirements in order to keep
security guarantees intact. Generally, it
is safest to generate a random IV, since
it will be both unpredictable and have a
very low chance of being non-unique. IVs
do not have to be kept secret, so if
generating duplicate IVs is a concern, a
list of already-used IVs can be kept and
checked against.

NIST offers recommendations on generation of IVs for modes of which they have approved. These include options for when random IVs are not practical. For CBC, CFB, and OFB, see [REF-1175]; for GCM, see [REF-1178].

In the following examples, CBC mode is used when encrypting data:

EVP_CIPHER_CTX ctx;char key[EVP_MAX_KEY_LENGTH];char iv[EVP_MAX_IV_LENGTH];RAND_bytes(key, b);memset(iv,0,EVP_MAX_IV_LENGTH);EVP_EncryptInit(&ctx,EVP_bf_cbc(), key,iv);

public class SymmetricCipherTest {
public static void main() {

byte[] text ="Secret".getBytes();byte[] iv ={0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};KeyGenerator kg = KeyGenerator.getInstance("DES");kg.init(56);SecretKey key = kg.generateKey();Cipher cipher = Cipher.getInstance("DES/CBC/PKCS5Padding");IvParameterSpec ips = new IvParameterSpec(iv);cipher.init(Cipher.ENCRYPT_MODE, key, ips);return cipher.doFinal(inpBytes);
}
}

In both of these examples, the initialization vector (IV) is always a block of zeros. This makes the resulting cipher text much more predictable and susceptible to a dictionary attack.

The Wired Equivalent Privacy (WEP) protocol used in the 802.11
wireless standard only supported 40-bit keys, and the IVs were only 24
bits, increasing the chances that the same IV would be reused for
multiple messages. The IV was included in plaintext as part of the packet, making
it directly observable to attackers. Only 5000 messages are needed
before a collision occurs due to the "birthday paradox" [REF-1176]. Some
implementations would reuse the same IV for each packet. This IV reuse
made it much easier for attackers to recover plaintext from
two packets with the same IV, using well-understood attacks,
especially if the plaintext was known for one of the packets [REF-1175].

CVE-2020-1472
ZeroLogon vulnerability - use of a static IV of all zeroes in AES-CFB8 mode
https://www.cve.org/CVERecord?id=CVE-2020-1472

CVE-2011-3389
BEAST attack in SSL 3.0 / TLS 1.0. In CBC mode, chained initialization vectors are non-random, allowing decryption of HTTPS traffic using a chosen plaintext attack.
https://www.cve.org/CVERecord?id=CVE-2011-3389

CVE-2001-0161
wireless router does not use 6 of the 24 bits for WEP encryption, making it easier for attackers to decrypt traffic
https://www.cve.org/CVERecord?id=CVE-2001-0161

CVE-2001-0160
WEP card generates predictable IV values, making it easier for attackers to decrypt traffic
https://www.cve.org/CVERecord?id=CVE-2001-0160

CVE-2017-3225
device bootloader uses a zero initialization vector during AES-CBC
https://www.cve.org/CVERecord?id=CVE-2017-3225

CVE-2016-6485
crypto framework uses PHP rand function - which is not cryptographically secure - for an initialization vector
https://www.cve.org/CVERecord?id=CVE-2016-6485

CVE-2014-5386
encryption routine does not seed the random number generator, causing the same initialization vector to be generated repeatedly
https://www.cve.org/CVERecord?id=CVE-2014-5386

CVE-2020-5408
encryption functionality in an authentication framework uses a fixed null IV with CBC mode, allowing attackers to decrypt traffic in applications that use this functionality
https://www.cve.org/CVERecord?id=CVE-2020-5408

CVE-2017-17704
messages for a door-unlocking product use a fixed IV in CBC mode, which is the same after each restart
https://www.cve.org/CVERecord?id=CVE-2017-17704

CVE-2017-11133
application uses AES in CBC mode, but the pseudo-random secret and IV are generated using math.random, which is not cryptographically strong.
https://www.cve.org/CVERecord?id=CVE-2017-11133

CVE-2007-3528
Blowfish-CBC implementation constructs an IV where each byte is calculated modulo 8 instead of modulo 256, resulting in less than 12 bits for the effective IV length, and less than 4096 possible IV values.
https://www.cve.org/CVERecord?id=CVE-2007-3528

Cryptography

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.

CWE Content Team
MITRE
2021-03-09
4.4
2021-03-15

CWE Content Team
MITRE
2021-07-20
updated Maintenance_Notes, Observed_Examples, References

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

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

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