CWE-1204: Generation of Weak Initialization Vector (IV)
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.
Last updated
Overview
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.
Real-world CVEs
3 recorded CVEs are caused by CWE-1204 (Generation of Weak Initialization Vector (IV)). The highest-severity and most recent are shown first. 0 new CWE-1204 CVEs have been recorded so far in 2026 (2 in 2025).
Common consequences
What can happen when CWE-1204 is exploited.
Read Application Data
Affects: Confidentiality
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].
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
How to prevent it
Practical mitigations for CWE-1204, grouped by where in the lifecycle they apply.
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].
How to detect it
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.)
Effectiveness: High
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
In the following examples, CBC mode is used when encrypting data:
Vulnerable example
EVP_CIPHER_CTX ctx;Vulnerable example
public class SymmetricCipherTest {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].
Illustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- CVE-2020-1472CISA KEV— ZeroLogon vulnerability - use of a static IV of all zeroes in AES-CFB8 mode
- 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.
- CVE-2001-0161 — wireless router does not use 6 of the 24 bits for WEP encryption, making it easier for attackers to decrypt traffic
- CVE-2001-0160 — WEP card generates predictable IV values, making it easier for attackers to decrypt traffic
- CVE-2017-3225 — device bootloader uses a zero initialization vector during AES-CBC
- CVE-2016-6485 — crypto framework uses PHP rand function - which is not cryptographically secure - for an initialization vector
- CVE-2014-5386 — encryption routine does not seed the random number generator, causing the same initialization vector to be generated repeatedly
- 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
- CVE-2017-17704 — messages for a door-unlocking product use a fixed IV in CBC mode, which is the same after each restart
- 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.
- 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.
Attack patterns
CAPEC attack patterns that exploit this weakness.
Frequently asked questions
Common questions about CWE-1204.
- What is CWE-1204?
- 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.
- What CVEs are caused by CWE-1204?
- 3 recorded CVEs are attributed to CWE-1204, including CVE-2022-26083, CVE-2025-0714, CVE-2023-2747.
- How do you prevent CWE-1204?
- 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.
- How is CWE-1204 detected?
- 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.)
- What are the consequences of CWE-1204?
- Exploiting CWE-1204 can lead to: Read Application Data.
- Is CWE-1204 actively exploited?
- 3 recorded CVEs are caused by CWE-1204; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-1204) (opens in a new tab)
- CWE-1204 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-1204
Get alerted the moment a new CWE-1204 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.