The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.

Primary

Implementation
Developers often choose default values that leave the product as open and easy to use as possible out-of-the-box, under the assumption that the administrator can (or should) change the default value. However, this ease-of-use comes at a cost when the default is insecure and the administrator does not change it.

System Configuration

Other
Varies by Context
The impact of insecure defaults varies widely
depending on the functionality that the product
controls.

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

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

CVE-2022-42467
A generic database browser interface has a default mode that exposes a web server to the network, allowing queries to the database.
https://www.cve.org/CVERecord?id=CVE-2022-42467

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.

This entry improves organization of concepts under initialization. The typical CWE model is to cover "Missing" and "Incorrect" behaviors. Arguably, this entry could be named as "Incorrect" instead of "Insecure." This might be changed in the near future.

CWE Content Team
MITRE
2019-03-25
3.3
2019-06-20

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2021-07-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

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

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Common_Consequences, Description, Detection_Factors, Modes_of_Introduction, References, Relationships, Time_of_Introduction

Anonymous External Contributor
2023-10-13
Suggested name change for clarity

Insecure Default Initialization of Resource