GitLab CVE-2026-85706路径遍历漏洞分析与蓝队处置

导语：GitLab 于 9 月 10 日修复了 CVE-2026-85706，评分高达 CVSS 10.0。该漏洞位于自托管实例的仓库提交 API，攻击者无需账号、无需交互，单次 HTTP 请求即可读取服务器上的任意文件。不到 24 小时内，野外探测与利用已出现，CISA 随后将其列入已知被利用漏洞目录，并要求美国联邦民事机构在 9 月 14 日前完成修复。

一、漏洞概览

CVE-2026-85706 的核心问题有两个：一是路径限制不严，二是认证校验缺失。二者叠加后，GitLab CE/EE 自托管实例的仓库提交 API 被暴露为“未认证任意文件读取”入口。成功利用后，攻击者可读取配置文件、CI/CD 变量、部署令牌、SSH 私钥和源代码相关凭据。

受影响范围可精确定位：

18.7 及以上、低于 19.1.8 的版本
19.2 系列中低于 19.2.6 的版本
19.3 系列中低于 19.3.2 的版本

GitLab.com 托管平台已在该漏洞披露前完成修复；GitLab Dedicated 客户无需额外操作；风险主要落在各类自托管实例上。

同一补丁周期还修复了 CVE-2026-87719，这是 GitLab EE 中的一个 CVSS 9.9 反序列化问题，需要认证用户具备 Duo Chat 访问权限才可触发。它虽然不能像 CVE-2026-85706 那样直接无认证利用，但说明同一版本窗口内可能伴随多项高严重度缺陷，这也让“只修一个入口”的思路变得更危险。

二、技术分析

从蓝队角度看，这个漏洞之所以关键，不是“能读文件”这么简单，而是 GitLab 主机在开发与 CI/CD 链路上天然处于高信任位置。一旦文件读取成立，攻击者下一步很可能把服务器凭据转化为对代码、镜像、发布流程甚至云环境的进一步访问。

当前公开技术细节主要围绕以下几个风险文件展开：.gitlab_shell_secret、SSH 主机私钥、数据库配置、对象存储与 SMTP 凭据、OAuth 与 webhook 集成令牌、个人访问令牌、项目/组级 deploy token，以及 CI/CD 变量。换句话说，单点文件读取很可能变成供应链链路的横向跳板。

MITRE ATT&CK 视角下，利用行为最接近 T1083（文件和目录发现）与 T1552（不安全凭据存储）。如果攻击者把读取到的令牌用于后续访问代码库或流水线，又会落到 T1078（有效账户）和 T1195（供应链妥协）的后续阶段。也就是说，这个漏洞不是孤立事件，而是一个“读取即铺垫”的入侵前置动作。

三、野外利用与时间线

公开时间线相当紧迫。GitLab 在 2026 年 9 月 10 日披露漏洞，9 月 11 日 CISA 就将其纳入已知被利用漏洞目录，并给美国联邦民事机构设定了 9 月 14 日的修复截止时间。多个安全团队在披露后不到 24 小时便观测到了面向该漏洞的主动探测行为。

目前公开来源没有把活动归因到某个命名攻击组织，也没有确认与某次勒索软件活动直接相关。但历史模式很清楚：GitLab 的路径遍历类文件读取漏洞往往在披露后几天内就被快速武器化，CVE-2023-2825 就是前例。因此，对自托管实例来说，这更像“已经在被利用”而不是“未来可能被利用”。

四、蓝队检测与响应

这是当前最需要落地的部分。首先是补丁与资产确认：所有生产、待机、预发、灾备实例都要升级到受影响分支的修复版本，并重启服务后再次确认运行版本。GitLab Dedicated 客户除外，但也要和供应商确认托管实例状态。

其次是日志狩猎。GitLab 的 api_json.log 和 production_json.log 是结构化请求来源，但不要忽略 NGINX 访问日志、反向代理或 WAF 日志、负载均衡日志，以及任何仍保留的数据包/流日志。重点应放在对仓库提交 API 的 HTTP POST 请求上，尤其是包含 file.path 参数、路径分隔符、 traversal 风格编码、未认证身份、异常响应体大小，或同一个源地址跨项目/跨实例高频访问的模式。watchTowr 与 SecurityAffairs 的报道都把这一 hunt lead 明确化了。

如果发现可疑访问，或者日志无法证明“读了什么”，就需要把响应从“文件可读范围”扩大到“这些文件会授予哪些权限”。也就是说，蓝队不是在追一个读取动作，而是在评估读取动作可能开启的后门、令牌、流水线访问和云权限。不要把轮换和调查割裂开：先保留 API、Rails、NGINX、WAF、身份和主机侧的遥测，再把可疑读取与后续登录、令牌使用、仓库访问、CI/CD 活动做关联。

五、长期防御与修复建议

如果把 CVE-2026-85706 看作一次紧急补丁，那后续阶段其实是凭据和信任边界重建。数据库凭据、对象存储凭据、SMTP、OAuth、webhook、集成、deploy token、个人访问令牌、runner 注册信息都可能受到影响，需要按拥有者职责分批轮换。CI/CD 所有者还要复核最近流水线、runner 注册、变量修改、release 和 package registry 活动，隔离高权限 runner，避免不可信项目直接享用持久 runner。

GitLab 管理员需要特别谨慎处理 gitlab-secrets.json。GitLab 官方明确警告，若数据库加密主键轮换不当，可能导致数据库中已有加密值无法解密。因此必须按文档流程执行，并在变更前后验证解密能力，而不是直接暴力重置。

在网络层面，临时策略包括将无法立即升级的实例从不受信网络隔离、限制管理入口访问、清理 DNS 与负载均衡上的废弃实例。但 WAF 规则不能替代补丁，尤其不能视为对各类编码变体的完整防护。最终，补丁关闭的是读取路径，轮换、会话回收和 CI/CD 权限清理才关闭攻击者可能已经打开的下游路径。

参考资料：