External Initialization of Trusted Variables or Data Stores

Draft Base
Structure: Simple
Description

This vulnerability occurs when an application sets up its critical internal variables or storage systems using data from untrusted, external sources that an attacker could control.

Extended Description

A secure system should be cautious about trusting any data that originates from outside its own controlled environment. When core application variables or data stores—like configuration flags, security tokens, or internal state trackers—are populated with user-supplied or externally-provided values, attackers can feed them malicious data. This allows them to manipulate the application's logic from the very start, often leading to severe security breaches. In practice, this means developers must ensure that all trusted variables are initialized with hard-coded values, secure internal processes, or rigorously validated data. Relying on external inputs for initialization, even if those inputs are later checked, creates a dangerous window where the system's foundational state is compromised. Always establish critical internal state independently, before processing any untrusted data.

Common Consequences 1
Scope: Integrity

Impact: Modify Application Data

An attacker could gain access to and modify sensitive data or system information.

Potential Mitigations 2
Phase: Implementation

Strategy: Input Validation

A product system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking (e.g. input validation) is performed when relying on input from outside a trust boundary.
Phase: Architecture and Design
Avoid any external control of variables. If necessary, restrict the variables that can be modified using an allowlist, and use a different namespace or naming convention if possible.
Demonstrative Examples 2
In the Java example below, a system property controls the debug level of the application.

Code Example:

Bad
Java
java
If an attacker is able to modify the system property, then it may be possible to coax the application into divulging sensitive information by virtue of the fact that additional debug information is printed/exposed as the debug level increases.
This code checks the HTTP POST request for a debug switch, and enables a debug mode if the switch is set.

Code Example:

Bad
PHP
php

/.../*

php
Any user can activate the debug mode, gaining administrator privileges. An attacker may also use the information printed by the phpinfo() function to further exploit the system. .
This example also exhibits Information Exposure Through Debug Information (Insertion of Sensitive Information Into Debugging Code)
Observed Examples 5
CVE-2022-43468WordPress module sets internal variables based on external inputs, allowing false reporting of the number of views
CVE-2000-0959Does not clear dangerous environment variables, enabling symlink attack.
CVE-2001-0033Specify alternate configuration directory in environment variable, enabling untrusted path.
CVE-2001-0872Dangerous environment variable not cleansed.
CVE-2001-0084Specify arbitrary modules using environment variable.
Applicable Platforms
Languages:
PHP : SometimesNot Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Taxonomy Mapping
  • PLOVER
  • Software Fault Patterns
Notes
RelationshipOverlaps Missing variable initialization, especially in PHP.
Applicable Platform This is often found in PHP due to register_globals and the common practice of storing library/include files under the web document root so that they are available using a direct request.