Jenkins Git Parameter Plugin 未验证输入漏洞

漏洞信息

漏洞名称： Jenkins Git Parameter Plugin 未验证输入漏洞

漏洞编号：

• CVE： CVE-2025-53652

漏洞类型： 命令执行

漏洞等级： 高危

漏洞描述： Jenkins是一个开源的自动化服务器，广泛用于持续集成和持续交付（CI/CD）流程中。Jenkins Git Parameter Plugin是Jenkins的一个插件，用于在构建过程中提供Git参数的支持。该插件在处理用户输入的Git参数时存在未验证输入漏洞，导致攻击者可以通过构造恶意的Git参数执行任意命令。

漏洞的根源在于Jenkins Git Parameter Plugin在处理用户提供的Git参数时，未对输入进行适当的验证和清理。攻击者可以通过HTTP POST请求提交恶意的JSON负载，其中包含可以注入到Git命令中的shell命令。由于这些参数被直接传递到Git CLI命令中而没有经过适当的转义或验证，攻击者可以在Jenkins构建主机上执行任意命令。

此漏洞的影响非常严重，因为它允许攻击者在Jenkins服务器上执行任意命令，可能导致数据泄露、服务中断或进一步的系统入侵。由于Jenkins通常用于自动化构建和部署流程，攻击者可以利用此漏洞破坏整个CI/CD管道。此外，由于漏洞的利用不需要认证，任何能够提交构建请求的用户都可能利用此漏洞。因此，建议用户和管理员立即更新到修复了此漏洞的版本，并审查所有可能受影响的构建参数。

产品厂商： Jenkins

产品名称： Jenkins Git Parameter Plugin

来源： https://github.com/pl4tyz/CVE-2025-53652-Jenkins-Git-Parameter-Analysis

类型： CVE-2025:github search

仓库文件

• README.md
• checkout.png
• checkoutCommand.png
• createValue.png
• execute.png
• gitParameterValue.png
• stringParameter.png

来源概述

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 GitParameterValue, 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
   “

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.
   

6. 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.