The product initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.
A product system should be reluctant to trust variables that have been initialized outside of its trust boundary, especially if they are initialized by users. The variables may have been initialized incorrectly. If an attacker can initialize the variable, then they can influence what the vulnerable system will do.
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.
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.
An attacker could gain access to and modify sensitive data or system information.
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-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.