2026-09-07 04:16:10 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： Jenkins于9月2日发布安全公告修复超20个漏洞，本文重点分析其中四个高危插件漏洞：Performance插件反序列化RCE、FileParameter路径穿越、SAML插件越权及EntraID插件提权。四个漏洞根因均为Stapler数据绑定信任问题与权限校验缺失，攻击链覆盖CI/CD多个层面。建议运维人员立即更新受影响插件至修复版本，并可通过界面、CLI或RESTAPI自查插件版本。 综合评分： 88 文章分类： 漏洞分析,WEB安全,渗透测试,漏洞预警

Jenkins 四连击：反序列化 RCE + 路径穿越 + SAML 越权 + Entra 提权

撅人

2026年9月5日 00:00 广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

🔴 导语 · CI/CD 安全紧急预警

运维 Jenkins 的 DevOps 和安全团队请注意！⚠️

Jenkins 9 月 2 日发布大规模安全公告，一次性修复超过 20 个漏洞，涉及核心框架和十多个插件。今天重点拆解其中四个最值得关注的插件漏洞——从 Item/Configure 权限打到控制器 RCE，从低权限用户越权到管理员，从 Entra 组名冒充到权限提升，覆盖了 CI/CD 攻击链的多个层面。

💀 CVE-2026-84670 · Performance 插件反序列化（最危险）——拥有 Item/Configure 权限的攻击者通过恶意序列化报告文件，在 Jenkins 控制器上执行任意代码。典型的”工作区 → 控制器”攻击路径。

📁 CVE-2026-84671 · File Parameter 路径穿越——@DataBoundConstructor 缺参数名校验，../ 序列穿越写入控制器任意位置，远程代码执行。

🔑 CVE-2026-84668 · SAML 插件越权——低权限用户通过表单数据绑定覆盖 IdP 元数据文件，伪造任意用户身份登录 Jenkins。

👥 CVE-2026-84672 · Entra ID 插件权限提升——Entra 组显示名称不唯一，攻击者创建同名组即可继承特权组权限。

四个漏洞的共同根因是 Jenkins 生态中反复出现的Stapler 数据绑定信任问题和权限校验缺失。如果你在 Jenkins 上装了这些插件，今天就要更新。

🔍 漏洞速览

| | | | | | | | — | — | — | — | — | — | | CVE | 插件 | 类型 | 所需权限 | 影响 | 危险度 | | -84670 | Performance | Java 反序列化 | Item/Configure | 控制器 RCE | Critical | | -84671 | File Parameter | 路径穿越 | 可提交构建参数 | 任意文件写→RCE | High | | -84668 | SAML | 权限绕过 | 可提交相关表单 | 任意用户身份 | High | | -84672 | Entra ID | 权限提升 | 租户内可创建组 | 特权组权限 | Medium |

注：四个漏洞均于 2026-09-03 披露，均为 Jenkins 9 月安全公告的一部分。公告还包含 Jenkins core 及十多个其他插件的漏洞修复。

💀 CVE-2026-84670：Performance 插件反序列化 → 控制器 RCE

四个漏洞里最危险的一个——从工作区的 Item/Configure 权限一路打到 Jenkins 控制器上的任意代码执行。

漏洞原理（3 层拆解）

① 什么是 Performance 插件？

Performance Plugin 用于解析 JMeter、JUnit 等性能测试结果并在 Jenkins 界面展示性能趋势。为了加速重复构建的报告解析，插件会把解析后的报告以 Java 序列化格式缓存为 .serialized 文件，存放在控制器的构建目录中。

② 漏洞出在哪？

AbstractParser 的 loadSerializedReport 方法读取 .serialized 文件后，通过 ObjectInputStreamWithClassMapping 反序列化。这个类的 resolveClass 只映射了三个旧版类名做兼容，其余类名全部回退到 ObjectInputStream 默认解析——没有类白名单限制。

那恶意序列化数据怎么进到控制器的构建目录？通过 copyReportsToMaster——它根据 Job 配置的报告文件通配符，把工作区里的文件复制到控制器的构建目录。拥有 Item/Configure 权限的攻击者可以配置通配符匹配 .serialized 文件，让恶意序列化数据随报告进入控制器。

攻击链：

攻击者有 Item/Configure 权限 → 修改 Job 配置
配置报告文件通配符包含 *.serialized
在工作区放入恶意 .serialized 文件（ysoserial 生成的 gadget）
copyReportsToMaster 把 .serialized 复制到控制器构建目录 ⚠️
loadSerializedReport 反序列化 → 无类限制 → RCE！💥

③ 为什么是 Critical？

Item/Configure 是 Jenkins 中相对常见的权限——很多团队给开发人员 Job 配置权限以允许他们调整构建参数。而 Jenkins 控制器通常是 CI/CD 体系的核心节点，上面存储了大量凭证（Git token、部署密钥、云凭证等）。从 Job 配置权限打到控制器 RCE，意味着攻击者可以窃取所有凭证、接管所有构建流水线、横向移动到整个基础设施。

✅ 修复方案做了什么？

干脆利落地移除了整个序列化缓存机制：删除 loadSerializedReport、saveSerializedReport 和 ObjectInputStreamWithClassMapping，解析时直接重新读取原始报告文件，不再写入或读取 .serialized 缓存。PerformanceReportMap、PerformanceProjectAction 与 PerformancePublisher 同步删除对 .serialized 文件的过滤逻辑。没有反序列化，就没有反序列化漏洞。

📁 CVE-2026-84671：File Parameter 路径穿越 → 任意文件写 → RCE

又是 Stapler 数据绑定 + 路径穿越的经典组合——@DataBoundConstructor 只在定义路径做了校验，写入路径忘了校验。

漏洞原理

File Parameter Plugin 允许在构建参数中接收用户上传的文件。StashedFileParameterValue 有一个 @DataBoundConstructor 标注的构造函数：

@DataBoundConstructor

public StashedFileParameterValue(String name, FileItem file) {

// name 直接来自表单提交，攻击者可控

new File(tmpDir, name); // 直接拼接路径！⚠️

}

参数名的合法性校验只存在于 AbstractFileParameterDefinition 创建参数定义的构造路径中——那是管理员配置 Job 时的路径。但 @DataBoundConstructor 标注的构造器（用户提交构建参数时触发）没有做同样的校验。

攻击者把 name 参数设为 ../../../../evil.dll，上传的文件就会被写到 JENKINS_HOME/stashedFileParameterValueFiles/../../../../evil.dll——也就是控制器文件系统的任意位置。写任意文件到 Jenkins 控制器上，后续转 RCE 的路径就很多了。

✅ 修复方案做了什么？

在 AbstractFileParameterValue 新增 safeName() 方法，用正则 [A-Za-z][A-Za-z0-9._-]{2,50} 对参数名做白名单校验。@DataBoundConstructor 构造器的写盘路径全部改为使用 safeName()，不合规参数名统一回退为固定值 fileparam，彻底阻断路径穿越。

🔑 CVE-2026-84668：SAML 插件越权 → 伪造任意用户身份

低权限用户覆盖 IdP 元数据 → 让 Jenkins 信任攻击者控制的身份提供方 → 以任意用户身份登录。 这是认证层面的全面突破。

漏洞原理

SAML 插件用 SamlSecurityRealm 对接外部 IdP 做单点登录。它的构造函数标注了 @DataBoundConstructor，Stapler 框架处理表单提交时会自动实例化并绑定数据。

问题在于：这个构造函数在缺少权限校验的情况下，直接调用了 idpMetadataConfiguration.createIdPMetadataFile()，把提交的 XML 内容写入 Jenkins 控制器上的 saml-idp-metadata.xml。

能够提交相关表单的低权限攻击者，就可以把 IdP 元数据覆盖成自己控制的内容——让 SAML 认证流程信任攻击者的身份提供方。之后攻击者用自己的 IdP 签发任意用户的 SAML 断言，就能以管理员身份登录 Jenkins。

① 低权限用户提交 SAML 配置表单（包含恶意 IdP 元数据 XML）

② @DataBoundConstructor 触发 → 无权限校验 → createIdPMetadataFile() 写入 saml-idp-metadata.xml

③ Jenkins SAML 配置被改写 → 信任攻击者的 IdP

④ 攻击者用自己的 IdP 签发 admin 用户断言 → 登录 Jenkins → 管理员权限！

✅ 修复方案做了什么？

在 @DataBoundConstructor 标注的构造函数入口新增 Jenkins.get().checkPermission(Jenkins.ADMINISTER) 校验，要求调用者具备 Overall/Administer 权限。缺少该权限的表单数据绑定在写入 IdP 元数据文件前被拒绝。

👥 CVE-2026-84672：Entra ID 组名冒充 → 权限提升

用”显示名称”做权限判定的经典陷阱——显示名称既不唯一也非不可变，攻击者建个同名组就能蹭权限。

漏洞原理

Microsoft Entra ID（Azure AD）插件通过 OAuth 2.0 / OpenID Connect 完成用户认证，配合权限矩阵策略实现基于 Entra 组的授权。

问题出在 AzureAdUser.setAuthorities 方法——它把用户所属每个 Entra 组的显示名称（group.getGroupName()）无条件加入 Spring Security 权限列表。

但 Entra 组的显示名称有两个致命问题：

• 不唯一——租户内可以有多个显示名称完全相同的组

• 非不可变——组名随时可以改

更关键的是：租户默认允许任意成员创建指定显示名称的组。所以攻击者可以：

攻击步骤：

发现 Jenkins 用 “DevOps-Admins” 这个组授予管理员权限
攻击者在 Entra 中创建一个也叫 “DevOps-Admins” 的组
把自己加入这个组 ⚠️
登录 Jenkins → setAuthorities 加入 “DevOps-Admins” 权限
权限判定匹配到 “DevOps-Admins” → 管理员权限！💥

权限判定时，ObjId2FullSidMap.getOrOriginal 按前缀 显示名称 ( 将裸显示名称解析为授权配置中的 显示名称 (对象ID) 条目——也就是说，即使管理员是按对象 ID 配置的权限，攻击者用显示名称也能匹配上。

✅ 修复方案做了什么？

默认禁用基于显示名称的组授权。setAuthorities 默认只保留组的唯一对象 ID（GUID）作为权限。显示名称前缀回退仅在系统属性 com.microsoft.jenkins.azuread.ObjId2FullSidMap.enableDisplayNameAuthorization 显式设为 true 时生效，且排除形如 x (objectId) 的显示名称。这个开关仅作为迁移到按对象 ID 授权前的短期过渡手段。

⏱️ 3 秒自查

四个插件的风险矩阵：

自查命令：

方法 1：Jenkins 界面查看

Manage Jenkins → Plugins → Installed plugins

搜索 performance / file-parameters / saml / azure-ad

方法 2：Jenkins CLI 列出插件

jenkins-cli -s https://jenkins.example.com list-plugins \

| grep -iE “performance|file-parameters|saml|azure-ad”

方法 3：REST API 查询

curl -s “https://jenkins.example.com/pluginManager/api/json?depth=1” \

| jq ‘.plugins[] | select(.shortName==”performance” or .shortName==”file-parameters” or .shortName==”saml” or .shortName==”azure-ad”) | {shortName, version}’

🛡️ 修复方案

✅ 方案一：更新插件（根治）

在 Jenkins 插件管理器中更新以下插件：

• Performance Plugin → 升级到 1017.v9e9f7b_b_b_c5e7 或更高

• File Parameter Plugin → 升级到 433.va_0b_80359d54d 或更高

• SAML Plugin → 升级到 4.623.v7875d61cd9f5 或更高

• Microsoft Entra ID Plugin → 升级到 711.v34046f788fd7 或更高

同时建议检查并更新 Jenkins 核心及其他所有插件——本次公告涉及 20+ 漏洞，全面更新最稳妥。

⚠️ 方案二：临时缓解

Performance 插件：

• 限制 Item/Configure 权限——只授予可信管理员

• 或暂时卸载 Performance 插件（如非必需）

File Parameter 插件：

• 限制构建参数提交权限——只允许可信用户触发构建

• 或暂时禁用 Stashed File Parameter 类型

SAML 插件：

• 确保 SAML 配置页面只有管理员能访问

• 定期检查 saml-idp-metadata.xml 是否被篡改

Entra ID 插件：

• 按对象 ID（GUID）配置组权限，不要按显示名称配置

• 在 Entra ID 中限制普通用户创建组的权限

⚠️ 以上只是临时措施——根治必须更新插件。

🕵️ 排查清单

Performance 反序列化

☐ 检查构建目录中是否有可疑的 .serialized 文件（大小异常、时间异常）

☐ 检查 Job 配置中性能报告的通配符是否包含 .serialized

☐ 检查 Jenkins 控制器进程是否有异常子进程或网络连接

File Parameter 路径穿越

☐ 检查 JENKINS_HOME/stashedFileParameterValueFiles 目录及上级目录是否有异常文件

☐ 检查是否有包含 ../ 序列的参数名配置

SAML 越权

☐ 检查 saml-idp-metadata.xml 是否与预期一致

☐ 检查近期是否有非预期的管理员登录记录

Entra ID 提权

☐ 检查 Jenkins 权限配置是否按显示名称而非对象 ID 授权

☐ 检查 Entra ID 中是否有与特权组同名的可疑组

☐ 如确认被利用——检查 Jenkins 审计日志、轮换凭证、审查所有组权限配置

⚠️ 安全提醒

这四个漏洞，加上本次公告中的其他十几个，暴露了 Jenkins 生态中长期存在的两个系统性安全问题：

问题一：Stapler 数据绑定的信任模型。 @DataBoundConstructor 是 Jenkins 插件中极其常见的注解——它让 Stapler 框架自动把表单数据绑定到 Java 对象。但这个机制的设计前提是”所有能提交表单的用户都有权限操作该对象”——而现实往往不是这样。四个漏洞中有两个（SAML、File Parameter）直接源于 @DataBoundConstructor 路径缺少权限校验或参数校验。Stapler 框架本身不负责权限检查，每个插件必须自己在构造函数里加——而这恰恰是最容易被遗漏的。

问题二：CI/CD 流水线权限的”梯度信任”缺失。 Jenkins 的权限模型通常是”要么全有要么全无”——Job 配置权限往往意味着能做很多事情。但 CI/CD 流水线本身是从代码到部署的全链路，工作区到控制器之间的边界（agent → master）本应该是强信任边界。Performance 插件的反序列化漏洞证明了这道边界有多脆弱——Item/Configure 权限就能一路打到控制器 RCE。在 CI/CD 安全设计中，永远不要假设工作区的数据是可信的——任何从工作区流向控制器的数据都应该被严格校验。

最后提醒：本次 Jenkins 9 月安全公告包含 20+ 漏洞，涉及 Jenkins core、Stapler 框架、以及十多个插件。上面四个只是插件中最值得单独拎出来讲的，core 的反序列化、XSS、CSRF 泄露等问题同样严重。建议一次性全量更新 Jenkins core 和所有插件，而不是只挑这四个。

转发给你们 DevOps、Jenkins 运维和安全团队——CI/CD 是供应链的核心，守住它就是守住整个研发体系的安全。

📎 官方参考

• Jenkins 安全公告 2026-09-02（完整列表）：jenkins.io/security/advisory/2026-09-02

• SAML 插件（SECURITY-4065）：SECURITY-4065

• Performance 插件（SECURITY-4026）：SECURITY-4026

• File Parameter 插件（SECURITY-4093）：SECURITY-4093

• Entra ID 插件（SECURITY-3935）：SECURITY-3935

本文仅供安全研究与防御参考，修复请以 Jenkins 官方公告为准。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：撅人《Jenkins 四连击：反序列化 RCE + 路径穿越 + SAML 越权 + Entra 提权》