GitLab 于周三发布社区版(CE)和企业版(EE)更新，修复了十几个漏洞和安全问题，其中包含一个允许未经身份验证用户在服务器上执行任意代码的“紧急”级漏洞。GitLab强烈建议客户尽快升级到已修复版本。值得注意的是，这已是 GitLab 在两个月内经历的第四个严重安全问题，而补丁中一行未被列入 CVE 清单的修复说明，还牵出了 AI 代理信任边界的新隐患。

核心漏洞：正则表达式编译器中的整数溢出

本次最严重的安全问题被标记为“紧急”，编号 CVE-2026-110264，属于整数溢出问题。

GitLab 在公告中表示：“GitLab 已修复一个问题，在特定条件下，由于编译特制的正则表达式时发生整数溢出，该问题可能允许未经身份验证的用户在 GitLab 服务器上执行任意代码。”公告还提到，除标准补丁版本外，该修复程序已回传至 GitLab CE/EE 版本 18.11.13、19.0.10、19.1.9 和 19.2.9。

受影响的 GitLab CE/EE 版本包括：

18.11.13 之前的 7.0 及所有版本

19.0.10 之前的 19.0 版本

19.1.9 之前的 19.1 版本

19.2.9 之前的 19.2 版本

19.3.6 之前的 19.3 版本

19.4.3 之前的 19.4 版本

19.5.1 之前的 19.5 版本

已修复的版本包括： 19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10 和 18.11.13。

高危漏洞：LDAP 账户可被静默接管

补丁还修复了一个被追踪为 CVE-2026-15723 的高危漏洞，涉及 OmniAuth-to-LDAP 自动链接电子邮件查找中的身份验证不当问题，影响 GitLab CE/EE。

GitLab 将其定性为严重问题：“当 OmniAuth SAML 和 LDAP 自动链接同时启用时，由于在 OmniAuth 身份链接期间使用的 LDAP 电子邮件查找路径中存在输入清理不当的问题，已认证用户可以在无需目标用户任何交互的情况下接管现有的 LDAP 账户。”

两个月内的第四个严重安全问题

依据现有素材，这已是 GitLab 在两个月内经历的第四个严重安全问题：

今年 10 月早些时候，GitLab 修复了一个最高严重级别的正则表达式漏洞;

9 月，它修复了 CVE-2026-85706，该漏洞的严重程度同样被评为满分 10 分;

另一份 9 月份的报告揭示了一个令人担忧的问题：一个使 CI/CD 安全面临风险的长期有效代币。

分析师：问题根源在依赖项，而非 GitLab 自研代码

分析师和顾问一致认为，当前的漏洞非常严重，值得立即采取行动。

Digital 520 首席顾问 Noah Kenney 指出：“该问题源于正则表达式编译器中的整数溢出，而非 GitLab 专门开发的功能。”他强调，这种区别很重要，因为它突显了与依赖项和共享软件组件相关的风险。“组织可以投入大量资金来保护自己的应用程序，但仍可能暴露在通过底层库和框架引入的漏洞中。这个问题可能影响追溯到 GitLab 7.0 版本的发布，这表明这些漏洞在被发现和修复之前可能会持续存在多久。”

Dickson Research 首席分析师 Frank Dickson 也持类似观点：“该漏洞存在于 Ruby 中，而不仅仅是 GitLab 自己的代码里。GitLab 的发布说明显示，修复方案是以补丁形式发布到 Ruby 的正则表达式处理模块中，其检测机制之一就以 Ruby 的正则引擎 Onigmo 命名。GitLab 可能不是唯一携带此漏洞的 Ruby 应用程序。首席信息安全官(CISO)应该询问他们的其他供应商。”

被“埋没”的修复：AI 代理信任边界引发关注

Kenney 补充说，CISO 应特别关注 GitLab 帖子中简短提到的一点。

“在那些被埋没的漏洞修复中，甚至连 CVE 列表里都没有提到，有一行关于从 Workhorse 中剥离客户端提供的 MCP 工具的信任标志的说明，”他说。“简单来说，GitLab 发现了一条 AI 代理可能被授予不应信任的工具的路径，并悄无声息地修复了它。这引发了关于 AI 赋能系统中信任边界的重要问题。”

为什么 GitLab 漏洞格外危险

Dickson 指出，这些漏洞尤其令人担忧，因为 GitLab 系统的集成度极高。

“GitLab 不仅仅是一个代码仓库。它保存着源代码、CI/CD 流水线，以及这些流水线在部署到生产环境时经常使用的密钥，”他说。“掌控 GitLab 服务器就意味着掌握了通往王国的钥匙。当构建生产环境的系统会替攻击者完成这一切时，他们根本不需要入侵生产环境。”

部署提醒：为停机时间做计划

Dickson 还指出，这些修复程序可能需要大量时间才能部署。

“要为停机时间做计划，”他说。“GitLab 的发布说明指出，此补丁包含数据库迁移，单节点实例在迁移期间将无法访问。有人会要求等到周末。等待本身就是一种风险接受。这个决定权属于高管，而非 DevOps 团队。”

审计追踪风险与被遗忘的服务器

咨询公司 UHY 合伙人 Ty Coffee 指出，LDAP 漏洞增加了在发生数据泄露后的调查中，无意间将责任推给无辜员工的风险。

“如果攻击者接管了基于 LDAP 的账户，他们所做的一切都会记录在合法员工的名下，而你的审计追踪就会指向错误的人，”Coffee 说道。“首席信息安全官还应检查影子和遗留的 GitLab 服务器，例如团队运行的实例、旧的灾难恢复副本、被收购公司的服务器，因为这会影响旧版本，这意味着被遗忘的服务器也在受控范围内。”

趋势判断与行动建议

综合现有素材，本次 GitLab 补丁释放出三个值得技术管理者关注的信号：

依赖项风险难以靠自身投入消除。 漏洞根源位于 Ruby 正则表达式编译器，而非 GitLab 自研功能，这意味着其他 Ruby 应用可能同样暴露，CISO 应将问询范围扩展至全部供应商。

AI 赋能系统的信任边界需要单独审视。 MCP 工具信任标志的剥离虽未列入 CVE 清单，却直接关系到 AI 代理是否会被授予不应信任的工具，这类“隐性修复”值得在安全评审中单独追踪。

补丁部署本身是一项管理决策。 数据库迁移带来的停机、遗留与影子实例的覆盖范围，都需要高管层而非仅 DevOps 团队来权衡风险接受。

行动建议： 对照受影响版本清单确认自身实例版本，尽快升级至 19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10 或 18.11.13;同时排查团队自建实例、灾难恢复副本及被收购公司遗留的 GitLab 服务器。