The product does not initialize a critical resource.
Many resources require initialization before they can be properly used. If a resource is not initialized, it could contain unpredictable or expired data, or it could be initialized to defaults that are invalid. This can have security implications when the resource is expected to have certain properties or values.
Explicitly initialize the resource before use. If this is performed through an API function or standard procedure, follow all specified steps.
Pay close attention to complex conditionals that affect initialization, since some branches might not perform the initialization.
Avoid race conditions (CWE-362) during initialization routines.
Run or compile your product with settings that generate warnings about uninitialized variables or data.
When reusing a resource such as memory or a program variable, the original contents of that resource may not be cleared before it is sent to an untrusted party.
The uninitialized resource may contain values that cause program flow to change in ways that the programmer did not intend.
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.)
CVE-2020-20739A variable that has its value set in a conditional statement is sometimes used when the conditional fails, sometimes causing data leakage
CVE-2005-1036Chain: Bypass of access restrictions due to improper authorization (CWE-862) of a user results from an improperly initialized (CWE-909) I/O permission bitmap