CWE-908: Use of Uninitialized Resource

Description:
The product uses or accesses a resource that has not been initialized.

Extended Description:
When a resource has not been properly initialized, the product may behave unexpectedly. This may lead to a crash or invalid memory access, but the consequences vary depending on the type of resource and how it is used within the product.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-665, CWE-665

Consequences:
  - Confidentiality: Read Memory
  - Availability: DoS: Crash, Exit, or Restart

Detection methods:
  - 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 havin

Mitigations:
  - [Implementation] Explicitly initialize the resource before use. If this is performed through an API function or standard procedure, follow all required steps.
  - [Implementation] Pay close attention to complex conditionals that affect initialization, since some branches might not perform the initialization.
  - [Implementation] Avoid race conditions (CWE-362) during initialization routines.
  - [Build and Compilation] Run or compile the product with settings that generate warnings about uninitialized variables or data.

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.

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.
$username = GetCurrentUser(); $state = GetStateData($username); if (defined($state)) { $uid = ExtractUserID($state); } 
                      
                      # do stuff 
                      if ($uid == 0) { DoAdminThings(); }

Real-world examples:
  - CVE-2019-9805: Chain: Creation of the packet client occurs before initialization is complete (CWE-696) resulting in a read from uninitialized memory (CWE-908), causing memory corruption.
  - CVE-2008-4197: Use of uninitialized memory may allow code execution.
  - CVE-2008-2934: Free of an uninitialized pointer leads to crash and possible code execution.
  - CVE-2008-0063: Product does not clear memory contents when generating an error message, leading to information leak.
  - CVE-2008-0062: Lack of initialization triggers NULL pointer dereference or double-free.