CWE-453 is the product that initializes an internal variable, by default, with an insecure or less secure value than is possible.
The classic home for this is old PHP, but the idea applies anywhere a default decides a security outcome.
How it happens
MITRE's example is a login check in PHP:
// $user and $pass automatically set from POST request
if (login_user($user, $pass)) {
$authorized = true;
}
...
if ($authorized) {
generatePage();
}
$authorized is never initialized. With register_globals enabled, PHP sets it to any value found in the POST request. An attacker adds an unexpected third field, authorized set to true, and gets in without credentials.
The fix is to initialize explicitly, and to read inputs deliberately:
$user = $_POST['user'];
$pass = $_POST['pass'];
$authorized = false;
if (login_user($user, $pass)) {
$authorized = true;
}
The observed example in the record is CVE-2022-36349, insecure default variable initialization in BIOS firmware for a hardware board that allows denial of service.
What an attacker gains
MITRE lists an integrity impact: the attacker could access and modify sensitive data or system information.
How to find it
MITRE notes that static analysis (SAST) can find some instances by modeling data flow. Also review configuration for settings that let external input create variables, and look for security decisions whose flag has no explicit starting value.
How to fix it
From the record: disable or change default settings when they can be used to abuse the system. Since defaults ship with the product, a potential attacker familiar with it is likely to know them. For example, change default credentials or disable the associated accounts.
In code, make the safe value the default. A flag that grants access should start as false. A limit should start at the strict end.
Quick check
Why did the PHP login example fail?
The authorized variable was never initialized, so with register_globals on, the request itself could set it.
