The product does not initialize critical variables, which causes the execution environment to use unexpected values.

Primary

Indirect

Implementation

Integrity
Other
Unexpected State
Quality Degradation
Varies by Context
The uninitialized data may be invalid, causing logic errors within the program. In some cases, this could result in a security problem.

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
Attack Surface Reduction
Ensure that critical variables are initialized before first use [REF-1485].

Requirements
Language Selection
Choose a language that is not susceptible to these issues.

This function attempts to extract a pair of numbers from a user-supplied string.

void parse_data(char *untrusted_input){
int m, n, error;error = sscanf(untrusted_input, "%d:%d", &m, &n);if ( EOF == error ){die("Did not specify integer value. Die evil hacker!\n");}
/* proceed assuming n and m are initialized correctly */

}

This code attempts to extract two integer values out of a formatted, user-supplied input. However, if an attacker were to provide an input of the form:

123:

then only the m variable will be initialized. Subsequent use of n may result in the use of an uninitialized variable (CWE-457).

Here, an uninitialized field in a Java class is used in a seldom-called method, which would cause a NullPointerException to be thrown.

private User user;public void someMethod() {

// Do something interesting.
...

// Throws NPE if user hasn't been properly initialized.
String username = user.getName();
}

This code first authenticates a user, then allows a delete command if the user is an administrator.

if (authenticate($username,$password) && setAdmin($username)){$isAdmin = true;}
/.../

if ($isAdmin){deleteUser($userToDelete);}

The $isAdmin variable is set to true if the user is an admin, but is uninitialized otherwise. If PHP's register_globals feature is enabled, an attacker can set uninitialized variables like $isAdmin to arbitrary values, in this case gaining administrator privileges by setting $isAdmin to true.

In the following Java code the BankManager class uses the user variable of the class User to allow authorized users to perform bank manager tasks. The user variable is initialized within the method setUser that retrieves the User from the User database. The user is then authenticated as unauthorized user through the method authenticateUser.

public class BankManager {

// user allowed to perform bank manager tasks
private User user = null;private boolean isUserAuthentic = false;

// constructor for BankManager class
public BankManager() {...}

// retrieve user from database of users
public User getUserFromUserDatabase(String username){...}

// set user variable using username
public void setUser(String username) {this.user = getUserFromUserDatabase(username);}

// authenticate user
public boolean authenticateUser(String username, String password) {if (username.equals(user.getUsername()) && password.equals(user.getPassword())) {isUserAuthentic = true;}return isUserAuthentic;}

// methods for performing bank manager tasks
...
}

However, if the method setUser is not called before authenticateUser then the user variable will not have been initialized and will result in a NullPointerException. The code should verify that the user variable has been initialized before it is used, as in the following code.

public class BankManager {

// user allowed to perform bank manager tasks
private User user = null;private boolean isUserAuthentic = false;

// constructor for BankManager class
public BankManager(String username) {user = getUserFromUserDatabase(username);}

// retrieve user from database of users
public User getUserFromUserDatabase(String username) {...}

// authenticate user
public boolean authenticateUser(String username, String password) {
if (user == null) {System.out.println("Cannot find user " + username);}else {if (password.equals(user.getPassword())) {isUserAuthentic = true;}}return isUserAuthentic;
}

// methods for performing bank manager tasks
...

}

This example will leave test_string in an
unknown condition when i is the same value as err_val,
because test_string is not initialized
(CWE-456). Depending on where this code segment appears
(e.g. within a function body), test_string might be
random if it is stored on the heap or stack. If the
variable is declared in static memory, it might be zero
or NULL. Compiler optimization might contribute to the
unpredictability of this address.

char *test_string;
if (i != err_val)
{
test_string = "Hello World!";
}
printf("%s", test_string);

When the printf() is reached,
test_string might be an unexpected address, so the
printf might print junk strings (CWE-457).

To fix this code, there are a couple approaches to
making sure that test_string has been properly set once
it reaches the printf().
One solution would be to set test_string to an
acceptable default before the conditional:

char *test_string = "Done at the beginning";
if (i != err_val)
{
test_string = "Hello World!";
}
printf("%s", test_string);

Another solution is to ensure that each
branch of the conditional - including the default/else
branch - could ensure that test_string is set:

char *test_string;
if (i != err_val)
{
test_string = "Hello World!";
}
else {
test_string = "Done on the other side!";
}
printf("%s", test_string);

Consider the following merchant server application as implemented in
[REF-1475]. It receives card payment information (orderPgData instance
in OrderPgData.java) from the payment gateway (such as PayPal). The
next step is to complete the payment (finalizeOrder() in
Main.java). The merchant server validates the amount (validateAmount()
in OrderPgData.java), and if the validation is successful, then the
payment is completed.

File: OrderPgData.java

public class OrderPgData {

String PgType;
int productPrice;
int paymentAmount;
private boolean isPaymentAmountTampered;

public boolean getIsPaymentAmountTampered() {

return this.isPaymentAmountTampered;

}

...

public void validateAmount() {

... [sets this.setIsPaymentAmountTampered to true or false depending on whether the product price matches the payment amount]

}

File: PgServiceResolver.java

public class PgServiceResolver {

public OrderPgData getOrderPgDataByPgType(String pgType, int productPrice, int paymentAmount) {

...
switch(pgType) {

case "card":

System.out.println("In "+pgType+" payment logic, orderPgData does not verify whether the product amount and payment amount have been tampered with.");
break;

case "paypal":

System.out.println("In "+pgType+" payment logic, orderPgData verifies whether the product amount and payment amount have been tampered with.");
orderPgData.validateAmount();
break;

}
...

File: Main.java

public class Main {

public static void main(String[] args) {

String pgType = "card"; // or paypal
int productPrice = 100;
int paymentAmount = 10;
PgServiceResolver pgServiceResolver = new PgServiceResolver();
OrderPgData orderPgData = pgServiceResolver.getOrderPgDataByPgType(pgType, productPrice, paymentAmount);
finalizeOrder(orderPgData);

}
private static void finalizeOrder(OrderPgData orderPgData) {

if (orderPgData.getIsPaymentAmountTampered()) {

System.out.println("The attacker tampered with the payment amount, but product payment is canceled.");

} else {

... /* the product payment is completed */

}

}

}

In PgServiceResolver.java, when pgType is "card" indicating a card
payment, orderPgData.validateAmount() is not called - that is, the
amount is not validated to be the same as the expected price.
Since isPaymentAmountTampered is declared as a private boolean, but it
is not initialized, it is forcibly initialized to false by the Java
compiler [REF-1476].
If the adversary modifies the price, e.g., changing paymentAmount from
100 to 10, then no validation is performed. Since
isPaymentAmountTampered is "false" because of the default
initialization, the code finishes processing the payment because it
does not believe that the amount has been changed.

This weakness could be addressed by setting the value of
isPaymentAmountTampered to true. This is a "secure-by-default" value
that reflects a "default deny" policy - i.e., it's assumed that the
payment amount is tampered, and only a special validation step can
change this assumption.

File: OrderPgData.java
...

private boolean isPaymentAmountTampered = true;

CVE-2020-6078
Chain: The return value of a function returning a pointer is not checked for success (CWE-252) resulting in the later use of an uninitialized variable (CWE-456) and a null pointer dereference (CWE-476)
https://www.cve.org/CVERecord?id=CVE-2020-6078

CVE-2019-3836
Chain: secure communications library does not initialize a local variable for a data structure (CWE-456), leading to access of an uninitialized pointer (CWE-824).
https://www.cve.org/CVERecord?id=CVE-2019-3836

CVE-2018-14641
Chain: C union member is not initialized (CWE-456), leading to access of invalid pointer (CWE-824)
https://www.cve.org/CVERecord?id=CVE-2018-14641

CVE-2009-2692
Chain: Use of an unimplemented network socket operation pointing to an uninitialized handler function (CWE-456) causes a crash because of a null pointer dereference (CWE-476)
https://www.cve.org/CVERecord?id=CVE-2009-2692

CVE-2020-20739
A variable that has its value set in a conditional statement is sometimes used when the conditional fails, sometimes causing data leakage
https://www.cve.org/CVERecord?id=CVE-2020-20739

CVE-2005-2978
Product uses uninitialized variables for size and index, leading to resultant buffer overflow.
https://www.cve.org/CVERecord?id=CVE-2005-2978

CVE-2005-2109
Internal variable in PHP application is not initialized, allowing external modification.
https://www.cve.org/CVERecord?id=CVE-2005-2109

CVE-2005-2193
Array variable not initialized in PHP application, leading to resultant SQL injection.
https://www.cve.org/CVERecord?id=CVE-2005-2193

Missing Initialization

SFP1
Glitch in computation

ERR30-C
Set errno to zero before calling a library function known to set errno, and check errno only after the function returns a value indicating failure
CWE More Abstract

DCL04-PL
Always initialize local variables
Exact

DCL33-PL
Declare identifiers before using them
Imprecise

ASCSM-CWE-456

ASCRM-CWE-456

Allowed
This CWE entry is at the Variant 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.

This weakness is a major factor in a number of resultant weaknesses, especially in web applications that allow global variable initialization (such as PHP) with libraries that can be directly requested.
It is highly likely that a large number of resultant weaknesses have missing initialization as a primary factor, but researcher reports generally do not provide this level of detail.

PLOVER
2006-07-19
Draft 3
2006-07-19

Sean Eidemiller
Cigital
2008-07-01
added/updated demonstrative examples

Eric Dalci
Cigital
2008-07-01
updated Potential_Mitigations, Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Relationships, Other_Notes, Taxonomy_Mappings

CWE Content Team
MITRE
2010-02-16
updated Relationships

CWE Content Team
MITRE
2010-04-05
updated Applicable_Platforms, Demonstrative_Examples

CWE Content Team
MITRE
2010-06-21
updated Other_Notes, Relationship_Notes

CWE Content Team
MITRE
2011-03-29
updated Demonstrative_Examples

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2011-06-27
updated Common_Consequences, Relationships

CWE Content Team
MITRE
2012-05-11
updated References, Relationships

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

CWE Content Team
MITRE
2013-02-21
updated Name, Relationships

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2017-11-08
updated Taxonomy_Mappings

CWE Content Team
MITRE
2019-01-03
updated References, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2019-06-20
updated Relationships, Type

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2020-06-25
updated Demonstrative_Examples

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2020-12-10
updated Relationships

CWE Content Team
MITRE
2021-03-15
updated Demonstrative_Examples, Observed_Examples, Relationships

CWE Content Team
MITRE
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Demonstrative_Examples, Observed_Examples, References

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated Potential_Mitigations, References

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

Hyeongkwan Lee
SK Planet
2022-09-13
4.17
2025-04-03
provided demonstratuve example for Java boolean variables

Missing Initialization