CAPEC-77
Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.
On this page
Ask an AI about this attack pattern
Show the prompt
Explain the attack pattern CAPEC-77: Manipulating User-Controlled Variables: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/77.html and https://cve.bz/cve/capec/77?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.
How the attack unfolds
Explore
The attacker looks for a way in.
[Probe target application] The adversary first probes the target application to determine important information about the target. This information could include types software used, software versions, what user input the application consumes, and so on.
Experiment
They probe what they found.
[Find user-controlled variables] Using the information found by probing the application, the adversary attempts to manipulate many user-controlled variables and observes the effects on the application. If the adversary notices any significant changes to the application, they will know that a certain variable is useful to the application.
2 techniques
- Adversaries will try to alter many common variable names such as "count", "tempFile", "i", etc. The hope is that they can alter the flow of the application without knowing the inner-workings.
- Adversaries will try to alter known environment variables.
Exploit
They carry out the attack.
[Manipulate user-controlled variables] Once the adversary has found a user-controller variable(s) that is important to the application, they will manipulate it to change the normal behavior in a way that benefits the adversary.
Prerequisites
A variable consumed by the application server is exposed to the client.
A variable consumed by the application server can be overwritten by the user.
The application server trusts user supplied data to compute business logic.
The application server does not perform proper input validation.
Skills required
- Low skill
The malicious user can easily try some well-known global variables and find one which matches.
- Medium skill
The adversary can use automated tools to probe for variables that they can control.
Signs of an attack
A web penetration tool probing a web server may generate abnormal activities recorded on log files. Abnormal traffic such as a high number of request coming from the same client may also rise the warnings from a monitoring system or an intrusion detection tool.
Consequences
| Impact | Affects | Note |
|---|---|---|
| Modify Data | Integrity | |
| Execute Unauthorized Commands | Confidentiality, Integrity, Availability | Run Arbitrary Code |
| Read Data | Confidentiality | |
| Gain Privileges | Confidentiality, Access Control, Authorization |
Mitigations
Do not allow override of global variables and do Not Trust Global Variables.
If the register_globals option is enabled, PHP will create global variables for each GET, POST, and cookie variable included in the HTTP request. This means that a malicious user may be able to set variables unexpectedly. For instance make sure that the server setting for PHP does not expose global variables.
A software system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking is performed when relying on input from outside a trust boundary.
Separate the presentation layer and the business logic layer. Variables at the business logic layer should not be exposed at the presentation layer. This is to prevent computation of business logic from user controlled input data.
Use encapsulation when declaring your variables. This is to lower the exposure of your variables.
Assume all input is malicious. Create an allowlist that defines all valid input to the software system based on the requirements specifications. Input that does not match against the allowlist should be rejected by the program.
Weaknesses it exploits
- CWE-15 External Control of System or Configuration Setting
- CWE-94 Improper Control of Generation of Code
- CWE-96 Improper Neutralization of Directives in Statically Saved Code
- CWE-285 Improper Authorization
- CWE-302 Authentication Bypass by Assumed-Immutable Data
- CWE-473 PHP External Variable Modification
- CWE-1321 Improperly Controlled Modification of Object Prototype Attributes
Recent CVEs with these weaknesses
- 8.6CVE-2026-109097
A vulnerability has been identified in ROS# (All versions < V2.3.1). Affected systems do not properly escape text of message definition files. This could allow an attacker that is able to pass a crafted message definition file to the user …
- 2.0CVE-2026-125082
A security flaw has been discovered in sunkaifei FlyCMS up to e71738e0cfb7ffd48c2ce74242a2dbb43f84f25a. Affected by this vulnerability is the function ModelDataService.insertData of the file articles/detail.html of the component Content Re…
- 7.2CVE-2026-120009
SAP ABAP Developer Tools (AMDP Data Preview) does not perform sufficient validation and authorization checks within certain affected functionality. An attacker with high privileges could submit specially crafted input to inject and execute…
- 9.9CVE-2026-109803
SAP NetWeaver Knowledge Management (XML Forms) does not sufficiently restrict the selection of XSL transformations processed by the affected functionality. Under certain conditions, an authenticated user with access to the affected functio…
- 9.9CVE-2026-109795
SAP NetWeaver does not perform necessary authorization checks and lacks sufficient input validation in certain remote-enabled functionality. An attacker with low privileges could send specially crafted input through a remote interface to i…
- 6.5CVE-2026-125118
Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment. Prior to 6.13.12, 7.8.13, 8.24.7, and 9.11.4, Schema.prototype.virtual() builds nested virtual paths without applying the special-property validati…
- 8.2CVE-2026-125117
Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment. Prior to 6.13.12, 7.8.13, 8.24.7, and 9.11.4, Mongoose can descend into inherited properties while loading database documents in init(), setting do…
- 2.1CVE-2026-124621
A vulnerability was determined in kongxin-github Java_Library_Management_System up to 70a6eb6b96fe64575d8051f1a59055bfc5dc5885. This affects the function UpdateAdmin.deleteuser/UpdateAdmin.updateadmin/UpdateAdmin.updatepass/Book.addbook/Bo…
The newest records naming one of them. Each weakness's page lists them all.
Related attack patterns
- Part of
- CAPEC-22 Exploiting Trust in Client
Examples
PHP is a study in bad security. The main idea pervading PHP is "ease of use," and the mantra "don't make the …
PHP is a study in bad security. The main idea pervading PHP is "ease of use," and the mantra "don't make the developer go to any extra work to get stuff done" applies in all cases. This is accomplished in PHP by removing formalism from the language, allowing declaration of variables on first use, initializing everything with preset values, and taking every meaningful variable from a transaction and making it available. In cases of collision with something more technical, the simple almost always dominates in PHP.
One consequence of all this is that PHP allows users of a Web application to override environment variables with user-supplied, untrusted query variables. Thus, critical values such as the CWD and the search path can be overwritten and directly controlled by a remote anonymous user.
Another similar consequence is that variables can be directly controlled and assigned from the user-controlled values supplied in GET and POST request fields. So seemingly normal code like this, does bizarre things:
while($count<10){
// Do something
$count++;
}Normally, this loop will execute its body ten times. The first iteration will be an undefined zero, and further trips though the loop will result in an increment of the variable $count. The problem is that the coder does not initialize the variable to zero before entering the loop. This is fine because PHP initializes the variable on declaration. The result is code that seems to function, regardless of badness. The problem is that a user of the Web application can supply a request such as
GET /login.php?count=9
and cause $count to start out at the value 9, resulting in only one trip through the loop. Yerg.
Depending on the configuration, PHP may accept user-supplied variables in place of environment variables. PHP initializes global variables for all process environment variables, such as $PATH and $HOSTNAME. These variables are of critical importance because they may be used in file or network operations. If an adversary can supply a new $PATH variable (such as PATH='/var'), the program may be exploitable.
PHP may also take field tags supplied in GET/POST requests and transform them into global variables. This is the case with the $count variable we explored in our previous example.
Consider another example of this problem in which a program defines a variable called $tempfile. An adversary can supply a new temp file such as $tempfile = "/etc/passwd". Then the temp file may get erased later via a call to unlink($tempfile);. Now the passwd file has been erased--a bad thing indeed on most OSs.
Also consider that the use of include() and require() first search $PATH, and that using calls to the shell may execute crucial programs such as ls. In this way, ls may be "Trojaned" (the adversary can modify $PATH to cause a Trojan copy of ls to be loaded). This type of attack could also apply to loadable libraries if $LD_LIBRARY_PATH is modified.
Finally, some versions of PHP may pass user data to syslog as a format string, thus exposing the application to a format string buffer overflow.
See also: File upload allows arbitrary file read by setting hidden form variables to match internal variable names (CVE-2000-0860)
MITRE's words, unchanged: CAPEC-77 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.