GitLab CVSS 10.0 漏洞 CVE-2026-110264：未认证即可远程执行代码，自建实例如何排查与升级

事件概述：GitLab 紧急发布满分漏洞补丁

2026 年 10 月 21 日，GitLab 发布紧急安全更新，修复编号为 CVE-2026-110264 的严重漏洞，CVSS 评分为满分 10.0。该漏洞位于 GitLab 社区版（CE）与企业版（EE）的正则表达式编译相关组件中，在特定条件下，未经过身份验证的攻击者即可在自建（self-managed）GitLab 服务器上执行任意代码。

值得注意的是，受影响版本最早可追溯到 2014 年 6 月发布的 GitLab 7.0，时间跨度长达 12 年。按照 GitLab 常规维护策略，官方只保障当前版本及此前两个月度版本，此次因漏洞危害罕见地为 18.11、19.0、19.1、19.2 等超出维护周期的旧分支一并向后移植了补丁。漏洞由安全研究员 joaxcar 通过 HackerOne 漏洞赏金计划上报。

截至 10 月 22 日，GitLab 未观测到该漏洞的在野利用，CISA 已知被利用漏洞清单（KEV）也尚未收录，但参考近期同类高危漏洞"补丁发布数天内即遭扫描尝试"的先例，窗口期预计不会太长。

漏洞原理：一个 .org 文件如何变成远程代码执行

根据 GitLab 官方检测规则说明及多家安全机构的分析，该漏洞的触发路径与 GitLab 渲染 Emacs Org 格式（.org）文件有关。GitLab 通过 org-ruby 组件渲染 .org 文件，文件中的 #+TODO: 行可以定义自定义待办关键字；组件先对这些关键字做一次转义，随后又将未转义的原始关键字拼入第二个正则表达式。

Ruby 的正则引擎 Onigmo 使用固定位数的计数器记录循环次数。攻击者构造包含超长待办关键字的 #+TODO: 行，会让该计数器发生整数溢出（CWE-190）回绕为负数，引擎在匹配时便会写到所分配内存之外的位置。再配合堆内存布局（heap grooming），这次越界写最终可以演变为一次以 git 用户权限执行的系统命令调用。

攻击门槛方面：攻击者无需任何账号，只需要在目标实例上存在一个可以存放 .org 文件的公开项目，推送恶意文件并触发服务端渲染即可，全程不需要诱导其他用户点击。GitLab 官方将这种攻击形容为"a grind"——噪声大、多数尝试会失败，但攻击可以反复重试，这不降低其威胁等级。

影响范围：谁需要立刻重视

按 GitLab 官方及 CVE 记录口径，受影响版本为：7.0 以来至 18.11.13 之前、19.0.10 之前、19.1.9 之前、19.2.9 之前、19.3.6 之前、19.4.3 之前、19.5.1 之前的全部 CE/EE 版本；Omnibus、源码、Helm Chart 等自建部署方式均受影响。

已经安全的实例：GitLab.com 托管平台官方已完成修复；GitLab Dedicated 租户运行在 19.3.5-internal0、19.4.2-internal0 或更新内部版本上的已包含补丁，无需额外操作。

暴露面方面，Shadowserver 目前追踪到超过 2700 个直接暴露在互联网上的 GitLab CE 实例。需要特别提醒的是：10 月 12 日 GitLab 修复的另一起 CVSS 10.0 正则漏洞（CVE-2026-97229，位于 CI/CD 规则的正则路径，修复版本为 19.4.2 / 19.3.5 / 19.2.8）与本次是不同代码路径，当时打过补丁的实例依然在本漏洞影响范围内，必须再升级一次。

为什么自建 GitLab 的团队要当成最高优先级

GitLab 服务器上存放的远不止源代码。安全机构 SOC Prime 指出：仓库中通常包含源代码、CI/CD 配置、部署密钥、访问令牌、基础设施定义，以及与生产环境的连接。一旦服务器被以 git 用户身份执行代码，攻击者即可窃取凭据、篡改仓库、植入持久化后门，并进一步横向移动——本质上等于把软件供应链的钥匙交了出去。

对中小企业而言，不少团队把自建 GitLab 当作"内网工具"而疏于版本更新，恰是高风险群体；即使是仅在内网使用的实例，一旦有任一员工终端被攻破，也可能成为跳板。

排查思路：官方检测规则与日志检查

GitLab 为自建实例发布了两条检测规则："Onigmo native worker crash" 与 "Org mode render error burst"，可在 SIEM 或日志平台中据此配置监控。

需要客观说明的是：GitLab 官方明确提示，成功的利用"不会可靠地触发崩溃"，没有告警并不等于实例干净。建议按以下思路排查：

1）确认实例版本是否落在受影响列表内；2）检查是否存在异常创建的公开项目，尤其是包含超长 #+TODO: 行的 .org 文件，以及短时间内异常的渲染请求；3）检查 CI/CD 变量、Runner 令牌、部署密钥是否存在异常使用记录；4）若怀疑已被利用，应按失陷处理：轮换全部相关凭据与令牌，并审计近期仓库变更。

修复与缓解建议

GitLab 官方未提供可替代升级的配置层缓解方案，升级是唯一防护手段。升级请按保守流程操作：

1）确认版本：管理员可在后台管理区域查看当前版本；Omnibus 安装也可使用 sudo gitlab-rake gitlab:env:info 查询（各部署方式命令以官方文档为准）。

2）备份与快照：升级前对服务器或虚拟机做完整快照，并确认 GitLab 应用备份可用；建议先在测试环境验证同路径升级，再安排生产维护窗口。

3）按分支升级到对应修复版本：19.5 线升到 19.5.1；19.4 线升到 19.4.3；19.3 线升到 19.3.6；19.2 / 19.1 / 19.0 线分别升到 19.2.9 / 19.1.9 / 19.0.10；18.11 及更早分支（最早至 7.0）升到 18.11.13。Omnibus 升级后需要重启服务，重启前请评估业务影响，避开工作时间。

4）无法立即升级时的临时收敛（不构成修复）：通过网络白名单或 VPN 收敛 GitLab 的互联网暴露面；收紧实例注册与公开项目创建权限，减少攻击者可利用的"公开项目"载体；按上文加强日志监控。这些措施只能降低暴露面，不能替代补丁。

5）直接暴露在公网的实例优先处理；容器化或 Helm 部署的实例，同步将镜像升级至官方修复版本。

后续观察

"未认证 + CVSS 10.0 + 12 年影响面"的组合，意味着一旦公开利用代码出现，扫描与利用可能在短时间内爆发。建议持续关注 GitLab 官方安全公告与 CISA KEV 更新；同时，这是本月内第二起 GitLab 正则引擎满分漏洞，自建用户应对 GitLab 版本保持常态化跟踪，避免长期停留在旧分支。

本文信息以 GitLab 官方发布说明、CVE 记录及主流安全机构分析为准，具体升级命令与操作步骤请以官方文档为准。