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.
Last updated
Overview
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.
Real-world CVEs
4 recorded CVEs are caused by CWE-454 (External Initialization of Trusted Variables or Data Stores). The highest-severity and most recent are shown first. 3 new CWE-454 CVEs have been recorded so far in 2026 (1 in 2025).
- CVE-2026-54003
Kirby: External Initialization of the Panel on reverse proxy setups with the `Forwarded` header
Critical · CVSS 9.1 · EPSS 52th2026-07-09 - CVE-2026-26148
Microsoft Azure AD SSH Login extension for Linux Elevation of Privilege Vulnerability
High · CVSS 8.1 · EPSS 29th2026-03-10 - CVE-2025-36244
IBM AIX privilege escalation
High · CVSS 7.4 · EPSS 2th2025-09-16 - CVE-2026-48980
pam_usb: getenv() used in PAM context allows environment variable injection into local-check logic
Medium · CVSS 6.3 · EPSS 7th2026-06-18
Common consequences
What can happen when CWE-454 is exploited.
Modify Application Data
Affects: Integrity
An attacker could gain access to and modify sensitive data or system information.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
How to prevent it
Practical mitigations for CWE-454, grouped by where in the lifecycle they apply.
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.
How to detect it
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.)
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
In the Java example below, a system property controls the debug level of the application.
Vulnerable example
int debugLevel = Integer.getInteger("com.domain.application.debugLevel").intValue();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.
Vulnerable example
/.../
$debugEnabled = false;Illustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- 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.
Terminology & mappings
Mapped taxonomies
- PLOVER: External initialization of trusted variables or values
- Software Fault Patterns: Tainted input to variable (SFP25)
Frequently asked questions
Common questions about CWE-454.
- What is CWE-454?
- The product initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.
- What CVEs are caused by CWE-454?
- 4 recorded CVEs are attributed to CWE-454, including CVE-2026-54003, CVE-2026-26148, CVE-2025-36244.
- How do you prevent CWE-454?
- 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.
- How is CWE-454 detected?
- 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.)
- What are the consequences of CWE-454?
- Exploiting CWE-454 can lead to: Modify Application Data.
- Is CWE-454 actively exploited?
- 4 recorded CVEs are caused by CWE-454; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-454) (opens in a new tab)
- CWE-454 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-454
Get alerted the moment a new CWE-454 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.