Associated Vulnerability
Title:Jenkins plugin Git Parameter 安全漏洞 (CVE-2025-53652)Description:Jenkins Git Parameter Plugin 439.vb_0e46ca_14534 and earlier does not validate that the Git parameter value submitted to the build matches one of the offered choices, allowing attackers with Item/Build permission to inject arbitrary values into Git parameters.
Description
CVE-2025-53652: Jenkins Git Parameter Analysis
Readme
# CVE-2025-53652: Jenkins Git Parameter Plugin Unvalidated Input Vulnerability.
## Summary
This vulnerability arises because user-controlled input from Jenkins build parameters is injected unsafely into the Git checkout command.
User input is provided as a build parameter (e.g., gitParameters), which can contain malicious shell commands.
This parameter is wrapped into a GitParameterValue (extending StringParameterValue), whose buildEnvironment() method exposes it as an environment variable in the build context without sanitization.
During the SCM checkout process, Jenkins loads the build environment variables via build.getEnvironment().
The branch name used for the checkout (localBranchName) is obtained from these environment variables.
The branch name is then passed directly to the CheckoutCommand.branch() method.
Finally, CheckoutCommand.execute() invokes the underlying Git CLI command, which concatenates the branch name without validation or escaping.
This enables command injection, allowing an attacker to execute arbitrary shell commands on the Jenkins build host.
## Analysis
1. The method createValue that handles user input (e.g., from the HTTP POST JSON payload),This is where Jenkins accepts user-supplied parameter values via the request (for example, `"selected": "master; rm -rf /"`).
The input is wrapped into a `GitParameterValu`e, which extends `StringParameterValue`, without input sanitization or validation.
This means raw user data is accepted as a build parameter and stored as a `ParameterValue` instance.
2. The `GitParameterValue` class extending `StringParameterValue`, `GitParameterValue` inherits from `StringParameterValue` but adds no sanitization.
The constructor chain means the user input is now stored in an object that will later be used by Jenkins to build environment variables.
This propagates malicious input into Jenkins' build environment variables.
"
3. The `StringParameterValue` class and its `buildEnvironment` method, This method is crucial — it exposes the parameter as environment variables in the build context by doing
"
```java
env.put(name, value);
env.put(name.toUpperCase(Locale.ENGLISH), value);
```
Since the value is unsanitized user input, it allows malicious input to enter Jenkins’ environment variables, making it accessible to later processes like Git commands.
4. The `_checkout` method in the `GitSCM` plugin, This method calls `build.getEnvironment(listener)`, which collects environment variables including the malicious one set earlier.
It uses these variables to get the branch name (via `localBranchName`), which is then passed to the `CheckoutCommand`.
The environment variable from the malicious parameter flows directly into the checkout process.
5. The creation of the `CheckoutCommand` and setting the branch/ref with the user input, The `CheckoutCommand.branch(localBranchName)` uses the unsanitized environment variable.
Since `localBranchName` came from user-controlled env vars, it injects arbitrary commands into the checkout, This sets the stage for command injection when `execute()` is called.
7. The` CheckoutCommand.execute()` method which runs the Git CLI command, This is the final step where the injected branch string is passed directly to the system’s Git CLI without escaping or sanitization, As a result, the malicious payload is executed as shell commands, enabling remote code execution on the Jenkins host.
## Conclusion
This analysis reveals how Jenkins’ Git Parameter Plugin, combined with the Git SCM plugin, can lead to a critical command injection vulnerability. By unsafely exposing user-controlled parameter values as environment variables and subsequently passing them directly to Git CLI commands without proper sanitization, attackers can execute arbitrary commands on the Jenkins build server.
This chain of trust breakdown—from the initial malicious JSON payload to the final shell execution—highlights the importance of strict input validation and secure handling of build parameters in continuous integration systems.
Users and administrators should ensure they are running updated versions of Jenkins and all plugins, and carefully audit any parameters that influence shell commands. Mitigations such as input sanitization, whitelisting allowed branches, or isolating build environments can reduce the risk.
Understanding this flow equips security professionals and developers with the insight needed to detect, prevent, and remediate similar injection vulnerabilities in Jenkins or comparable CI/CD platforms.
File Snapshot
[4.0K] /data/pocs/df4e631ad5fb6ca3276fe035656e76c0e4273f0b
├── [ 76K] checkoutCommand.png
├── [ 88K] checkout.png
├── [103K] createValue.png
├── [ 54K] execute.png
├── [ 33K] gitParameterValue.png
├── [5.2K] README.md
└── [118K] stringParameter.png
0 directories, 7 files
Remarks
1. It is advised to access via the original source first.
2. Local POC snapshots are reserved for subscribers — if the original source is unavailable, the local mirror is part of the paid plan.
3. Mirroring, verifying, and maintaining this POC archive takes ongoing effort, so local snapshots are a paid feature. Your subscription keeps the archive online — thank you for the support. View subscription plans →