• CISA 为正遭利用的 GitLab 漏洞 CVE-2026-85706 设定的 9 月 14 日修复期限已过
  • GitLab 的修复方案需要执行数据库迁移，这会导致单节点安装停机；按正确流程升级的多节点部署则可避免停机

事实

CISA 针对 CVE-2026-85706 设定的 9 月 14 日修复期限已过。该 GitLab 漏洞正遭利用，在特定条件下可让未经身份验证的用户读取服务器上的文件。CISA 于 9 月 11 日将该漏洞加入其“已知被利用漏洞”目录。这项联邦期限适用于受此要求约束的美国联邦文职机构。

GitLab 于 9 月 10 日发布修复版本 19.3.2、19.2.6 和 19.1.8，并敦促受影响的自托管客户立即升级。GitLab.com 已完成修补，GitLab Dedicated 客户则无需采取行动。

此次更新包含数据库迁移。GitLab 表示，单节点安装在迁移完成前将不可用。运维方遵循该公司的零停机流程时，多节点安装可以在不停机的情况下完成升级。

分析

对于自行运行 GitLab 服务器的团队，这个补丁的棘手之处并不在于是否安装，而在于如何在开发人员可能正用来管理进行中发布的平台上，安排一次紧急数据库迁移。单节点实例必须停机，直至迁移完成。

等待业务较少的维护窗口，会让这个正遭利用的漏洞暴露更久。立即更新则可能中断代码仓库、合并请求及其他开发工作。多节点安装更具灵活性，但 GitLab 仍要求遵循正确的升级顺序；拥有多台机器并不会让数据库变更消失。

对 BTW 读者而言，这起事件清楚展示了自托管开发基础设施的运营成本。服务器和紧急维护窗口都由组织自行负责。GitLab.com 和 GitLab Dedicated 客户无需自行完成相关安全工作，而自托管运维方必须把同一修复安排进自己的发布日程，并在完成后确保服务顺利恢复。

后续观察

关注自托管运维方是否确认已安装修复版本，并成功完成数据库迁移。升级延迟、迁移失败或 GitLab 发布进一步指导，都将揭示紧急安全工作与开发日程发生冲突的环节。如果出现补丁安装前已遭利用的证据，还会增加一项单独的事件响应任务。