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.

Modes Of Introduction

Architecture and Design
Implementation

Applicable Platforms

Language

Name: PHP (Sometimes)
Class: Not Language-Specific (Undetermined)

Common Consequences

Observed Examples

Potential Mitigations

Phases : Implementation
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.
Phases : 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.

Vulnerability Mapping Notes

Rationale : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Notes

Overlaps Missing variable initialization, especially in PHP.

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.

Submission

Modifications