CWE-454 External Initialization of Trusted Variables or Data Stores

The product initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.

• Integrity: Modify Application Data — If an attacker can initialize the variable incorrectly, this can influence what the product will do. The attacker could gain access to and modify sensitive data or system information.

• [Implementation] 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. Ensure adequate checking (e.g. input validation) is performed when relying on input from outside a trust boundary. • [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.

• Automated Static Analysis: 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-43468: WordPress module sets internal variables based on external inputs, allowing false reporting of the number of views • CVE-2000-0959: Does not clear dangerous environment variables, enabling symlink attack. • CVE-2001-0033: Specify alternate configuration directory in environment variable, enabling untrusted path. • CVE-2001-0872: Dangerous environment variable not cleansed. • CVE-2001-0084: Specify arbitrary modules using environment variable.