CWE-665: Improper Initialization

Code Examples & CVEs

Demonstrative Examples

Here, a boolean initiailized field is consulted to ensure that initialization tasks are only completed once. However, the field is mistakenly set to true during static initialization, so the initialization code is never reached.

BadJava

private boolean initialized = true;public void someMethod() {                         if (!initialized) {                                                                                                   // perform initialization tasks                                  ...                                  initialized = true;                            }

The following code intends to limit certain operations to the administrator only.

If the application is unable to extract the state information - say, due to a database timeout - then the $uid variable will not be explicitly set by the programmer. This will cause $uid to be regarded as equivalent to "0" in the conditional, allowing the original user to perform administrator actions. Even if the attacker cannot directly influence the state data, unexpected errors could cause incorrect privileges to be assigned to a user just by accident.

BadPerl

$username = GetCurrentUser();$state = GetStateData($username);if (defined($state)) {$uid = ExtractUserID($state);}                                            # do stuff                      if ($uid == 0) {DoAdminThings();}

The following code intends to concatenate a string to a variable and print the string.

This might seem innocent enough, but str was not initialized, so it contains random memory. As a result, str[0] might not contain the null terminator, so the copy might start at an offset other than 0. The consequences can vary, depending on the underlying memory.

BadC

char str[20];strcat(str, "hello world");printf("%s", str);

Observed CVE Examples (16)

CVE-2001-1471

chain: an invalid value prevents a library file from being included, skipping initialization of key variables, leading to resultant eval injection.

View Details

CVE-2008-3637

Improper error checking in protection mechanism produces an uninitialized variable, allowing security bypass and code execution.

View Details

CVE-2008-4197

Use of uninitialized memory may allow code execution.

View Details

CVE-2008-2934

Free of an uninitialized pointer leads to crash and possible code execution.

View Details

CVE-2007-3749

OS kernel does not reset a port when starting a setuid program, allowing local users to access the port and gain privileges.

View Details

CVE-2008-0063

Product does not clear memory contents when generating an error message, leading to information leak.

View Details

CVE-2008-0062

Lack of initialization triggers NULL pointer dereference or double-free.

View Details

CVE-2008-0081

Uninitialized variable leads to code execution in popular desktop application.

View Details

CVE-2008-3688

chain: Uninitialized variable leads to infinite loop.

View Details

CVE-2008-3475

chain: Improper initialization leads to memory corruption.

View Details

CVE-2008-5021

Composite: race condition allows attacker to modify an object while it is still being initialized, causing software to access uninitialized memory.

View Details

CVE-2005-1036

Chain: Bypass of access restrictions due to improper authorization (CWE-862) of a user results from an improperly initialized (CWE-909) I/O permission bitmap

View Details

CVE-2008-3597

chain: game server can access player data structures before initialization has happened leading to NULL dereference

View Details

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)

View Details

CVE-2009-0949

chain: improper initialization of memory can lead to NULL dereference

View Details

CVE-2009-3620

chain: some unprivileged ioctls do not verify that a structure has been initialized before invocation, leading to NULL dereference

View Details

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Verify controls for CWE-665 with SSDF evidence

Use NIST SSDF verification and vulnerability-response practices to detect CWE-665, Improper Initialization, throughout the product lifecycle. Derive review questions, static or dynamic checks, and negative tests from the CWE's causal behavior; define the components and lifecycle stages each check covers; and retain findings with enough evidence to distinguish the root cause from symptoms and impacts. Track escapes and false negatives, then improve the verification plan after every confirmed occurrence.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Apply Language Selection controls for Improper Initialization

MITRE associates mitigation with Requirements, Architecture and Design, Implementation, and Build and Compilation; the listed strategies include Language Selection; documented detection approaches include Automated Dynamic Analysis, Manual Dynamic Analysis, and Automated Static Analysis. Use these source-defined anchors to turn CWE-665 into implementation, review, and verification checks for the affected component.

CWE-665: Improper Initialization — MITRE CWE

Triage CWE-665 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-665, Improper Initialization, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

Apply precise root-cause mapping to CWE-665

Apply MITRE's full root-cause mapping guidance when using CWE-665, Improper Initialization. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.

CVE to CWE Root Cause Mapping Guidance — MITRE CWE

Validate CWE-665 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-665, Improper Initialization. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick Tips — MITRE CWE

Frequently Asked Questions

What is CWE-665: Improper Initialization?+

CWE-665: Improper Initialization is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used. This can have security implications when the associated resource is expected to have certain properties or values, such as a variable that determines whether a user has been authenticated or not.

What are the security consequences of Improper Initialization?+

If exploited, CWE-665 (Improper Initialization) it can compromise Confidentiality, Access Control and Availability, leading to outcomes such as Read Memory, Read Application Data, Bypass Protection Mechanism and DoS: Crash, Exit, or Restart.

How do you prevent or mitigate Improper Initialization?+

Recommended mitigations for CWE-665 include: Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values. Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage. Pay close attention to complex conditionals that affect initialization, since some conditions might not perform the initialization.

Which programming languages are affected by Improper Initialization?+

CWE-665 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What are real-world examples of Improper Initialization?+

MITRE documents real CVEs mapped to CWE-665, including CVE-2001-1471, CVE-2008-3637, CVE-2008-4197, CVE-2008-2934 and CVE-2007-3749. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-665 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

CWE-665: Improper Initialization

Extended Description

Technical Details

Applicable To

Security Consequences

Scope

Impact

Scope

Impact

Scope

Impact

Mitigation Strategies

Phase

Description

Phase

Description

Phase

Description

Phase

Description

Phase

Description

Detection Methods

Code Examples & CVEs

Demonstrative Examples

Observed CVE Examples (16)

CWE Relationships

Parent Weaknesses

Source-backed guidance

Verify controls for CWE-665 with SSDF evidence

Apply Language Selection controls for Improper Initialization

Triage CWE-665 against known exploitation evidence

Apply precise root-cause mapping to CWE-665

Validate CWE-665 with root-cause mapping checks

Frequently Asked Questions

Learn More