CWE-1419 describes a product that tries to initialize a resource but does not do so correctly, leaving it in an unexpected, incorrect or insecure state when it is used.
It matters when the resource drives a security decision. MITRE's examples are a variable that says whether a user is authenticated, or a register or fuse value that sets a chip's security state.
How it happens
In software this often comes from implicit initialization, where the value is never set explicitly. In C, memory on the stack is not necessarily cleared when allocated. Many scripting languages quietly default to an empty, null or zero value. If your code assumes that default is safe, and it is not, you have a problem.
In hardware the same thing appears with reset values and fuses. After a reset, registers may start wrong, and fuses can be set to the wrong value during a stage of the product lifecycle.
/* Vulnerable pattern: 'authenticated' is never given a starting value. */
int authenticated;
if (check_password(user, pw)) {
authenticated = 1;
}
if (authenticated) { /* may read garbage when the check fails */
grant_access();
}
/* Fixed: start in the safe state. */
int authenticated = 0;
The observed examples in the record include a WordPress module that sets internal variables from external input, allowing false reporting of view counts (CVE-2022-43468), and BIOS firmware with an insecure default variable initialization that allows denial of service (CVE-2022-36349). Another chain describes a package change that made the gettext function use implicit initialization with a hard coded path under the user writable C: drive (CVE-2023-25815).
What an attacker gains
MITRE lists three families of impact: reading memory or application data, gaining privileges or assuming identity, and a varied "other" bucket that depends on how the resource is used and whether it affects security decisions.
How to find it
MITRE notes that static analysis (SAST) can find some instances by analyzing source or compiled code without running it. Compiler warnings about uninitialized variables are the cheapest first pass, and reviewing code that sets up security state is the second.
How to fix it
From the record:
- Choose the safest possible initialization for security related resources.
- Make sure every resource, whether a variable, buffer or register, is fully initialized.
- Look hard at complex conditionals and reset sources, since some paths may skip initialization.
- In design, state clearly what the initialization should be and confirm it has no security implications.
Quick check
Why is "safest possible" the right initial value?
If initialization is missed or delayed, the resource then sits in the state that grants least, such as not authenticated.
