The product, by default, initializes an internal variable with an insecure or less secure value than is possible.

Primary

Implementation

Integrity
Modify Application Data
An attacker could gain access to and modify sensitive data or system information.

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

System Configuration
Disable or change default settings when they can be used to abuse the system. Since those default settings are shipped with the product they are likely to be known by a potential attacker who is familiar with the product. For instance, default credentials should be changed or the associated accounts should be disabled.

This code attempts to login a user using credentials from a POST request:

// $user and $pass automatically set from POST request
if (login_user($user,$pass)) {$authorized = true;}
...

if ($authorized) {generatePage();}

Because the $authorized variable is never initialized, PHP will automatically set $authorized to any value included in the POST request if register_globals is enabled. An attacker can send a POST request with an unexpected third value 'authorized' set to 'true' and gain authorized status without supplying valid credentials.
Here is a fixed version:

$user = $_POST['user'];$pass = $_POST['pass'];$authorized = false;if (login_user($user,$pass)) {$authorized = true;}
...

This code avoids the issue by initializing the $authorized variable to false and explicitly retrieving the login credentials from the $_POST variable. Regardless, register_globals should never be enabled and is disabled by default in current versions of PHP.

CVE-2022-36349
insecure default variable initialization in BIOS firmware for a hardware board allows DoS
https://www.cve.org/CVERecord?id=CVE-2022-36349

Insecure default variable initialization

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 overlaps other categories, probably should be split into separate items.

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

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

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

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

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated Common_Consequences, Demonstrative_Examples, Relationships

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

CWE Content Team
MITRE
2014-07-30
updated Relationships

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms

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

CWE Content Team
MITRE
2020-02-24
updated Relationships, Time_of_Introduction

CWE Content Team
MITRE
2023-01-31
updated Description

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

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2023-10-26
updated Demonstrative_Examples, Observed_Examples

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