GitLab CVE-2026-85706 已出现活跃利用，自托管实例请立即修复

GitLab 自托管部署正面临一个需要优先处置的高危问题：CVE-2026-85706 是 GitLab Community Edition（CE，社区版）和 Enterprise Edition（EE，企业版）中的路径遍历漏洞，CVSS 3.1 评分为最高的 10.0。在特定条件下，未认证攻击者可借此读取 GitLab 服务器上任意可访问的文件。

这并非仅停留在理论层面。美国网络安全和基础设施安全局（CISA）已将其列入“已知遭利用漏洞”（KEV）目录；安全研究人员也在补丁发布后不久发现了针对互联网暴露实例的探测活动。32122

最优先事项：立即升级

如果自托管 GitLab 处于受影响版本，应尽快升级至以下修复版本或更新版本：

• 19.1.8 及以上
• 19.2.6 及以上
• 19.3.2 及以上

受影响范围为 GitLab CE/EE：18.7 至 19.1.8 之前的版本、19.2 至 19.2.6 之前的版本，以及 19.3 至 19.3.2 之前的版本。GitLab 于 2026 年 9 月 10 日发布修复。37

CISA 在 9 月 11 日将 CVE-2026-85706 加入 KEV 目录，并为适用范围内的美国联邦民事机构设定了 9 月 14 日的处置截止日期。该期限不会自动约束私营机构，但对于任何可从互联网访问的自托管部署而言，这一安排明确反映出漏洞的紧迫性。3

漏洞为何危险：未认证任意文件读取

漏洞位于 GitLab 的 Repository Commits API（仓库提交 API）。公开说明指出，根本原因是对用户可控路径的约束不足，以及认证机制未被正确强制执行。攻击者无需登录，在特定条件下即可读取 GitLab 服务进程有权限访问的任意文件。3

这主要是一个文件泄露漏洞。现有材料并不能证明 CVE-2026-85706 单独即可实现远程代码执行（RCE）。不过，任意文件读取可能暴露后续入侵所需的关键材料，具体取决于服务器配置，例如应用设置、访问令牌、SSH 密钥、数据库凭据及其他 GitLab 进程可读取的敏感信息。925

已出现利用活动，响应不能只停留在“打补丁”

安全公司 watchTowr 报告称，其蜜罐网络在 9 月 11 日已观察到针对该漏洞的在野探测。CISA 将漏洞纳入 KEV 目录同样是重要信号：该目录用于标识已有在野利用证据的漏洞。222

公开报道证实了探测和利用活动，但尚未明确单一攻击团伙、可靠的受害者数量，也未证明存在一条固定、通用的后渗透攻击链。因此，不能因为暂未发现已知入侵报告，就认定外网暴露的服务器未受影响。

对外网暴露实例，应按“潜在秘密泄露事件”处理

补丁可以阻止漏洞继续被利用，却无法收回攻击者此前可能已读取的数据。对于处于受影响版本且可从互联网访问的服务器，应在大规模清理前先保留证据，并评估 GitLab 服务账号在暴露期间能够读取哪些内容。

应优先审查并轮换可能暴露的凭据，包括：

• GitLab 应用和配置中的密钥；
• 配置文件中保存的数据库、Redis、对象存储、镜像仓库、SMTP、目录服务及身份提供商凭据；
• CI/CD 变量、部署令牌、访问令牌、Runner 令牌、部署密钥，以及作业或集成环境中挂载的凭据；
• 主机或 GitLab 服务进程可访问的云密钥、软件包仓库凭据、签名密钥、SSH 私钥和 TLS 私钥。

轮换应经过规划。更改应用密钥或与加密相关的设置，可能导致会话失效，也可能影响加密配置或第三方集成。建议先留存相关日志与配置证据，准备回滚和恢复方案，再按风险从高到低有序轮换。

排查方向：重点关注这一 API 路径

一个有价值的初始指标是针对 Repository Commits API 的 HTTP POST 请求：

/api/v4/projects/<id>/repository/commits/

已有报告建议重点查找带有 file.path 参数的请求。应在反向代理、负载均衡器、WAF 和 GitLab Rails 访问日志中，排查异常未认证请求、疑似经过编码的路径遍历输入、意外项目 ID、重复失败、枚举模式或异常大的响应内容。212426

还应调查疑似暴露窗口之后是否出现关联行为，例如：

• 新建或异常使用的令牌；
• Runner 注册；
• CI/CD 变量、流水线定义发生变更；
• 异常的项目导入；
• GraphQL 活动；
• 非预期的对外网络连接。

与此次发布相关的处置建议还包括审查提交记录、GraphQL 订阅、项目导入和 CI/CD 流水线。23

需要注意的是，日志检索无结果并不能证明安全。日志保留周期可能不足，应用日志未必记录了相关请求细节，而代理或 WAF 日志有时可能是唯一可用证据。

无法立刻升级时的临时措施

**升级才是正式修复措施。**若因紧急变更窗口等原因无法立即升级，可先通过 VPN 或仅允许获批网络访问的方式，限制 GitLab Web 与 API 服务的暴露面。

在反向代理或 WAF 上，对受影响的 Repository Commits API 路径实施严格限制，也许能在短期内降低风险；但这可能影响正常自动化流程，不能替代补丁升级。

对每一台受影响服务器，建议按以下顺序处理：

1. 盘点并排序：识别所有自托管实例，优先处置外网可达系统。
2. 升级修复：升级至 19.1.8、19.2.6、19.3.2 或更高版本。
3. 确认实际运行版本：变更后验证服务正在运行的版本。
4. 保留并审查日志：查找利用尝试与异常活动迹象。
5. 轮换潜在暴露的秘密信息：结合服务器可访问资源与业务影响，分阶段完成凭据轮换。

同批修复的其他漏洞

相关安全报告还提到，此次发布修复了两个 GitLab EE 漏洞：

• CVE-2026-87719：据报道为需认证的反序列化不安全问题，CVSS 评分 9.9；部分报道认为其与 Advanced Search 配置和凭据暴露有关。6
• CVE-2026-88765：据报道为需认证的远程代码执行风险，涉及导入经构造的恶意 Git 项目导出文件，CVSS 评分 8.5。625

这些漏洞的前提条件和影响与 CVE-2026-85706 不同。对于互联网暴露的自托管 GitLab 安装，未认证、且已出现活跃利用的任意文件读取漏洞仍应是隔离与事件响应的首要优先级。