CWE-454 is what happens when a product sets critical internal variables or data stores from inputs that untrusted actors can change. If the attacker can initialize the variable, they can steer what the system does.
It shows up in applications that read environment variables, system properties, request parameters or config files without asking who controls them.
How it happens
MITRE says a system should be reluctant to trust variables initialized outside its trust boundary, especially by users. Two examples from the entry.
A Java system property sets the debug level:
int debugLevel = Integer.getInteger("com.domain.application.debugLevel").intValue();
If an attacker can change that property, they can coax the application into printing more debug information, which can expose sensitive data.
A PHP script turns on debug mode from a POST field:
$debugEnabled = false;
if ($_POST["debug"] == "true") {
$debugEnabled = true;
}
function login($username, $password) {
if ($debugEnabled) {
echo 'Debug Activated';
phpinfo();
$isAdmin = true;
return true;
}
}
Any user can send debug=true and become an administrator.
Observed examples include:
- CVE-2022-43468: a WordPress module set internal variables from external inputs, allowing false reporting of the number of views.
- CVE-2000-0959: dangerous environment variables were not cleared, enabling a symlink attack.
- CVE-2001-0033: an environment variable specified an alternate configuration directory, enabling an untrusted path.
What an attacker gains
MITRE lists an integrity impact: the ability to access and modify sensitive data or system information. As the debug example shows, that can extend to privilege escalation.
How to find it
Static analysis (SAST) can find some instances by tracing data flow from external sources into critical variables. By hand, list every variable that controls security behavior, such as debug flags, paths, limits and roles, and trace where each one gets its value.
How to fix it
MITRE's mitigations:
- Be reluctant to trust variables initialized outside your trust boundary. Validate input from outside it.
- Avoid external control of variables. If it is necessary, restrict which variables can be modified using an allowlist, and use a separate namespace or naming convention where possible.
A safer debug switch reads from a server-side setting that clients cannot touch, and it never grants privileges:
$debugEnabled = (getenv('APP_DEBUG') === '1'); // set by operators only
Never tie debug output to a request field, and never let debug mode change who is an administrator.
Quick check
Why are environment variables a risk here?
Programs often trust them, but a local attacker or a misconfigured launcher can set them. Observed CVEs show dangerous variables not being cleared or an alternate configuration directory being chosen through one.
