10 月 21 日，GitLab 发布了一轮紧急安全更新。最值得注意的不是补丁数量，而是其中一个编号为 CVE-2026-110264 的漏洞：CVSS 10.0，未认证远程代码执行，影响自托管 GitLab，而且代码根源可以追溯到 2014 年。

对把 GitLab 放在公网、又把它当成代码和 CI/CD 中心的人来说，这不是“有空再升级”的级别。

漏洞本身

根据 GitLab 的公告，问题出在正则表达式编译器的整数溢出。攻击者构造一条特殊的正则表达式，在编译阶段触发溢出，最终可以在 GitLab 服务器上执行任意代码。整个过程不需要登录，也不需要用户点击什么。

CVSS 10.0 不是随手给的分数。它通常意味着攻击路径是远程的、不需要身份、不需要交互，而且成功后影响的是服务器本身。对 GitLab 这种系统来说，服务器权限往往不只是“一台机器”：仓库里的源代码、CI/CD 变量、访问令牌、镜像仓库凭据、生产环境连接信息，都可能在同一台机器上。

为什么影响会回溯到 2014 年

GitLab 在公告里把修复 backport 到 18.11.13、19.0.10、19.1.9 和 19.2.9 等版本。安全分析师的评价很直接：GitLab 几乎不会给这么老的分支发补丁，这次这么做，说明问题不轻。

这也解释了一个常见误区：很多人以为“我用的版本很旧，攻击者不会花时间研究”。但代码是继承的，旧版本里的同一个编译器、同一条解析路径，可能一直没变。攻击者不需要为每个版本单独写一套利用，只要找到共用的缺陷就够了。

截至 10 月 22 日中午，还没有公开的在野利用证据。但“没有证据”和“没有发生”是两件事，尤其是这种利用门槛低、影响面大的漏洞，窗口期通常不会太长。

10.0 分不等于每个实例都同等危险

CVSS 描述的是漏洞本身的最坏情况，不是你的实际暴露面。公网可达、允许匿名访问、又没有前置认证代理的实例，风险最高；只在内网、访问受控的实例，优先级可以排后，但不能不修。

还有一个容易被忽略的点：GitLab 的补丁按版本线分发，多节点、Geo 部署、容器化部署都要逐个确认。只升级了 Web 节点，后台 job 节点还是旧版本，攻击面仍然在。

GitLab 的公告没有公开利用细节，这给了防守方一点时间，但也意味着很难靠请求特征去拦截。能确认的东西只有三样：版本、暴露面，以及日志里有没有不该出现的行为。

先确认你在不在影响面里

GitLab.com 和 GitLab Dedicated 由官方托管，已经修复；需要自己动手的是 self-managed 实例。检查顺序可以这样：

  • 先确认实例版本，以及是否暴露在公网。只在内部网络不等于安全，但公网实例应该优先处理。
  • 对照官方公告里的受影响版本和修复版本，升级到对应分支的最新补丁版本。
  • 如果暂时不能升级，至少限制访问来源、加一层认证代理，并密切看日志；但这只是临时缓解，不能替代补丁。
  • 升级后不要立刻结束。检查 GitLab 日志和系统日志里有没有异常崩溃、渲染错误、意外的 shell 执行，或者不正常的仓库、流水线变更。

补丁之后还要做什么

一个 CVSS 10.0 的未认证 RCE，最坏的情况不是漏洞被利用的那一刻，而是攻击者已经进来一段时间。GitLab 里保存的东西太适合做跳板了：改一改 CI 配置，就能把恶意代码送进生产；读一读环境变量，就能拿到云厂商的密钥；动一动仓库，就能污染下游。

所以升级只是第一步。比较稳妥的善后顺序是：

1. 轮换 GitLab 里保存的 CI/CD 变量、访问令牌、镜像仓库凭据和部署密钥。 2. 检查最近的流水线、制品、容器镜像和基础设施模板有没有被改动。 3. 检查是否有异常的管理员账号、SSH key、personal access token 和 webhook。 4. 如果发现被入侵的迹象，按供应链事件处理，不要只把服务器重装就结束。

为什么 GitLab 值得被当成一级资产

GitLab 不只是一个代码托管页面。它是很多团队的入口：开发者在这里登录，CI 在这里拿密钥，Runner 在这里执行代码，容器镜像从这里推到生产。攻破 GitLab 相当于拿到软件供应链的起点，而不是一台普通 Web 服务器。

这也是为什么“只在内网”不能成为不升级的理由。内网 GitLab 一旦被当成跳板，攻击者可以沿着 CI 的权限去碰生产；而公网 GitLab 连跳板都不用找，直接就能打。两种部署的风险模型不同，但结论一样：补丁要打，暴露面要收，凭据要能轮换。

这类漏洞为什么总在“编译器”里

正则表达式看起来只是文本匹配，但它背后是一个小型编译器：解析、生成指令、分配内存、处理边界。只要其中一步对长度的假设错了，就可能从“匹配失败”变成“内存越界”。这类问题难发现，因为正常输入永远不会碰到边界；也难审计，因为代码看起来只是处理字符串。

对普通开发者来说，能做的不是去读底层正则引擎的代码，而是接受一个现实：你依赖的基础设施，和你的业务代码一样需要补丁窗口。GitLab 不是“装好就不用管”的工具，它更像一台放在机房里、连着生产环境的编译服务器。

参考：TechTarget《Max-severity GitLab flaw lets attackers run code on servers》，2026 年 10 月 22 日；GitLab 官方安全公告 CVE-2026-110264。