devgo.cn你管理着一台自托管的 GitLab 服务器，一天早上你看到安全邮件：一个 CVSS 10.0 的漏洞正在被利用，攻击者不需要任何账号就能读取服务器上的任意文件——包括 CI/CD 变量、部署令牌、SSH 密钥。更糟的是，你的服务器只要有一个公开项目就满足了攻击条件。这不是演习。
这个漏洞编号是 CVE-2026-85706，本质上是一个路径遍历问题：GitLab 的仓库提交 API（也就是 `/api/v4/projects/{id}/repository/commits/` 这个接口，用来获取提交记录）在解析 `file.path` 参数时，没有把路径限制在项目目录内，同时也没有严格校验调用者身份。结果就是：未认证的远程攻击者可以构造像 `../../../../etc/passwd` 这样的路径，直接把服务器上的文件内容拉下来。
漏洞影响所有自管理的 GitLab CE/EE 版本，具体范围是 18.7 到 19.1.7、19.2 到 19.2.5、19.3 到 19.3.1。CVSS 评分满分 10.0，因为通过它不仅能读源码，还能拿走服务器上的密钥和配置，进而攻击 CI/CD 流水线，甚至横向渗透到 GitLab 能访问的其他系统。攻击条件极低：只要实例里存在至少一个公开项目，就可以直接发起请求，根本无需登录。
这个洞最初由安全研究员 Mohamed Abdelaiz（S3ntago）报告，GitLab 在 9 月 11 日发布了补丁。但正如安全公司 watchTowr 所披露的，补丁公开几小时内就有人在真实网络上扫描探测。之后美国 CISA 也把该漏洞加入了已知被利用漏洞（KEV）目录，意味着官方已经确认它在实际攻击中被使用。
修复本身不算复杂：把自托管的实例升级到 19.3.2、19.2.6 或 19.1.8 即可。补丁发布两周后，GitLab 还把修复回移植到了已经 EOL（停止维护）的 19.0.9 和 18.11.12 版本上，可见影响面之大。但升级补丁只是止血，正如安全公司高层 Christopher Houser 提醒的：“打补丁只能阻止新的读取，不能撤销攻击者已经拿走的部署令牌、CI 变量和 SSH 密钥。你必须轮换这些凭证，再检查你的构建在旧凭证有效期间拉过哪些包和镜像。”
也就是说，你不仅要修服务器，还要把可能被泄露的秘密全部换一遍。这听起来像额外工作量，但如果不做，攻击者早就可以用偷到的密钥继续入侵。另一位 CISO Parker Brisette 也强调，这个漏洞的威力在于 GitLab 上最常见的文件恰好是 CI/CD 变量、runner token（运行流水线的代理令牌）和日志里的敏感信息，而触发条件只有一个公开项目，之后就没有任何认证步骤。
那么怎么发现有没有被利用过？watchTowr 给出了一个非常实际的排查方法：去翻日志，找 HTTP POST 请求，目标 URI 是 `/api/v4/projects/{id}/repository/commits/`，且请求参数里带了 `file.path` 字段。如果发现这样的请求，基本可以确定有攻击尝试。这比事后分析内存快照要简单得多，也是每个运维团队都能立刻执行的动作。
我在整理这个案例时最意外的一点是：攻击条件如此简单，但很多团队平时根本没有意识到“公开项目”会带来这样的连锁风险。Reddit 上一位用户 GuffariBranderr8 的建议也很有价值：如果敏感配置或 CI/CD 凭据暴露了，攻击者可能用它跳转到其他系统，所以除了打补丁，还应限制 GitLab 的互联网暴露面，并轮换所有受影响密钥。
这件事给我们的启发很清楚：任何自托管的开发协作平台，只要暴露在公网，就必须假设它迟早会被盯上。补丁更新只是基础，更关键的是要有能力快速识别异常请求、轮换凭证，并对“公开项目”的使用保持警惕。即使你没有一个公开项目，也要检查一下是否有人误建了 public 仓库。毕竟一个 CVSS 10.0 的洞，可能就葬送在一个小小的公开项目上。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/news/2026/10/gitlab-critical-vulnerabilities/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global