| CARVIEW |
- Home
-
CWE Glossary Definition
CWE-457: Use of Uninitialized Variable
Weakness ID: 457Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.View customized information:For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.×
Edit Custom Filter
Description
The code uses a variable that has not been initialized, leading to unpredictable or unintended results.
Extended Description
In some languages such as C and C++, stack variables are not initialized by default. They generally contain junk data with the contents of stack memory before the function was invoked. An attacker can sometimes control or read these contents. In other languages or conditions, a variable that is not explicitly initialized can be given a default value that has security implications, depending on the logic of the program. The presence of an uninitialized variable can sometimes indicate a typographic error in the code.
Common Consequences
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
Impact Details Other
Scope: Availability, Integrity, Other Initial variables usually contain junk, which can not be trusted for consistency. This can lead to denial of service conditions, or modify control flow in unexpected ways. In some cases, an attacker can "pre-initialize" the variable using previous actions, which might enable code execution. This can cause a race condition if a lock variable check passes when it should not.Other
Scope: Authorization, Other Strings that are not initialized are especially dangerous, since many functions expect a null at the end -- and only at the end -- of a string.
Potential MitigationsPhase(s) Mitigation Implementation
Strategy: Attack Surface Reduction
Ensure that critical variables are initialized before first use [REF-1485].Build and Compilation
Strategy: Compilation or Build Hardening
Most compilers will complain about the use of uninitialized variables if warnings are turned on.Implementation; Operation
When using a language that does not require explicit declaration of variables, run or compile the software in a mode that reports undeclared or unknown variables. This may indicate the presence of a typographic error in the variable's name.Requirements
Strategy: Language Selection
Choose a language that is not susceptible to these issues.Architecture and Design
Mitigating technologies such as safe string libraries and container abstractions could be introduced.
Relationships
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name ChildOf 
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
908 Use of Uninitialized Resource CanFollow 
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
456 Missing Initialization of a Variable
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Nature Type ID Name ChildOf 
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
665 Improper Initialization
Relevant to the view "CISQ Data Protection Measures" (View-1340)
Nature Type ID Name ChildOf
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
665 Improper Initialization
Modes
Of IntroductionThe different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
Phase Note Implementation In C, using an uninitialized char * in some string libraries will return incorrect results, as the libraries expect the null terminator to always be at the end of a string, even if the string is empty.
Applicable PlatformsThis listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Languages C (Sometimes Prevalent)
C++ (Sometimes Prevalent)
Perl (Often Prevalent)
PHP (Often Prevalent)
Class: Not Language-Specific (Undetermined Prevalence)
Likelihood Of Exploit
High
Demonstrative ExamplesExample 1
This code prints a greeting using information stored in a POST request:
(bad code)Example Language: PHPif (isset($_POST['names'])) {$nameArray = $_POST['names'];}
echo "Hello " . $nameArray['first'];This code checks if the POST array 'names' is set before assigning it to the $nameArray variable. However, if the array is not in the POST request, $nameArray will remain uninitialized. This will cause an error when the array is accessed to print the greeting message, which could lead to further exploit.
Example 2
The following switch statement is intended to set the values of the variables aN and bN before they are used:
(bad code)Example Language: Cint aN, Bn;
switch (ctl) {}case -1:aN = 0;
bN = 0;
break;
case 0:aN = i;
bN = -i;
break;
case 1:aN = i + NEXT_SZ;
bN = i - NEXT_SZ;
break;
default:aN = -1;
aN = -1;
break;
repaint(aN, bN);In the default case of the switch statement, the programmer has accidentally set the value of aN twice. As a result, bN will have an undefined value. Most uninitialized variable issues result in general software reliability problems, but if attackers can intentionally trigger the use of an uninitialized variable, they might be able to launch a denial of service attack by crashing the program. Under the right circumstances, an attacker may be able to control the value of an uninitialized variable by affecting the values on the stack prior to the invocation of the function.
Example 3
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.
(bad code)Example Language: Cchar *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:
(good code)Example Language: Cchar *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:
(good code)Example Language: Cchar *test_string;
if (i != err_val)
{
test_string = "Hello World!";}
else {
test_string = "Done on the other side!";}
printf("%s", test_string);
Selected Observed
ExamplesNote: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
Reference Description Uninitialized variable leads to code execution in popular desktop application.Crafted input triggers dereference of an uninitialized object pointer.Crafted audio file triggers crash when an uninitialized variable is used.Uninitialized random seed variable used.
Weakness OrdinalitiesOrdinality Description Primary(where the weakness exists independent of other weaknesses) Detection
MethodsMethod Details Fuzzing
Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.Effectiveness: High
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
Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Nature Type ID Name MemberOf 
Category - a CWE entry that contains a set of other entries that share a common characteristic.398 7PK - Code Quality MemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic.998 SFP Secondary Cluster: Glitch in Computation MemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic.1180 SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL) MemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic.1416 Comprehensive Categorization: Resource Lifecycle Management
Vulnerability Mapping NotesUsage ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)Reason Acceptable-Use Rationale
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. Comments
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. Taxonomy
MappingsMapped Taxonomy Name Node ID Fit Mapped Node Name CLASP Uninitialized variable 7 Pernicious Kingdoms Uninitialized Variable Software Fault Patterns SFP1 Glitch in computation SEI CERT Perl Coding Standard DCL33-PL Imprecise Declare identifiers before using them References[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005.
<https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. (URL validated: 2024-11-17)[REF-436] mercy. "Exploiting Uninitialized Data". 2006-01.
<https://web.archive.org/web/20070403193636/https://www.felinemenace.org/~mercy/papers/UBehavior/UBehavior.zip>. (URL validated: 2025-07-24)[REF-437] Microsoft Security Vulnerability Research & Defense. "MS08-014 : The Case of the Uninitialized Stack Variable Vulnerability". 2008-03-11.
<https://msrc.microsoft.com/blog/2008/03/ms08-014-the-case-of-the-uninitialized-stack-variable-vulnerability/>. (URL validated: 2023-04-07)[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010. [REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Variable Initialization", Page 312. 1st Edition. Addison Wesley. 2006. [REF-1485] D3FEND. "D3FEND: D3-VI Variable Initialization".
<https://d3fend.mitre.org/technique/d3f:VariableInitialization/>. (URL validated: 2025-09-08) Content
History SubmissionsSubmission Date Submitter Organization 2006-07-19
(CWE Draft 3, 2006-07-19)CLASP 
ModificationsModification Date Modifier Organization 2025-12-11
(CWE 4.19, 2025-12-11)CWE Content Team MITRE updated Weakness_Ordinalities 2025-09-09
(CWE 4.18, 2025-09-09)CWE Content Team MITRE updated Potential_Mitigations, References 2023-06-29 CWE Content Team MITRE updated Mapping_Notes 2023-04-27 CWE Content Team MITRE updated Detection_Factors, References, Relationships 2021-07-20 CWE Content Team MITRE updated Observed_Examples 2021-03-15 CWE Content Team MITRE updated Demonstrative_Examples, Observed_Examples, Relationships 2020-12-10 CWE Content Team MITRE updated Relationships 2020-08-20 CWE Content Team MITRE updated Relationships 2020-02-24 CWE Content Team MITRE updated References, Relationships, Type 2019-06-20 CWE Content Team MITRE updated Relationships, Type 2019-01-03 CWE Content Team MITRE updated Taxonomy_Mappings 2017-11-08 CWE Content Team MITRE updated References, Relationships, Taxonomy_Mappings, White_Box_Definitions 2014-07-30 CWE Content Team MITRE updated Relationships, Taxonomy_Mappings 2014-06-23 CWE Content Team MITRE updated Modes_of_Introduction, Other_Notes 2013-02-21 CWE Content Team MITRE updated Applicable_Platforms, Description, Other_Notes, Potential_Mitigations, Relationships 2012-10-30 CWE Content Team MITRE updated Demonstrative_Examples 2012-05-11 CWE Content Team MITRE updated References, Relationships 2011-06-01 CWE Content Team MITRE updated Common_Consequences 2009-05-27 CWE Content Team MITRE updated Demonstrative_Examples 2009-03-10 CWE Content Team MITRE updated Demonstrative_Examples 2009-01-12 CWE Content Team MITRE updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations 2008-09-08 CWE Content Team MITRE updated Applicable_Platforms, Common_Consequences, Description, Relationships, Observed_Example, Other_Notes, References, Taxonomy_Mappings 2008-08-01 KDM Analytics added/updated white box definitions 2008-07-01 Eric Dalci Cigital updated Time_of_Introduction Previous Entry NamesChange Date Previous Entry Name 2008-04-11 Uninitialized Variable More information is available — Please edit the custom filter or select a different filter.Page Last Updated: December 11, 2025
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2026, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.
