2026年10月12日,GitLab发布了社区版和企业版的19.4.2、19.3.5和19.2.8版本。其中包含对CVE-2026-97229的修复,这是一个CVSS评分为10.0的漏洞,可能导致服务器上任意代码被执行。周四,美国CISA确认该漏洞正在被积极利用,并将其列入KEV目录。如果您自行管理GitLab实例,首要任务是立即更新。
在进入正题之前先了解几个术语。CVE是公开漏洞的编号。CVSS是从0到10的严重程度评分。CI/CD指自动编译、测试和发布代码的流水线。KEV是CISA收录已在真实攻击中被利用的漏洞的目录。RCE意为远程代码执行,即在他人的服务器上运行命令。
什么是CVE-2026-97229?
根据GitLab官方页面的说明,这是CI/CD配置所用正则表达式编译器中的整数溢出问题。在特定条件下,未经认证的用户可以利用精心构造的正则表达式在服务器上执行任意代码,原因是验证不充分。
该漏洞的CVSS向量为网络攻击、复杂度低、无需权限且无需用户交互,因此评分达到10.0。漏洞由joaxcar通过HackerOne的漏洞赏金计划报告。
谁在利用它?
据BleepingComputer报道,CISA已将该漏洞加入KEV,并要求联邦机构在周日前加固服务器。据The Hacker News,民用机构的截止日期为2026年11月1日。
此次列入KEV与Alpine Linux披露的一起事件有关。一名身份不明的攻击者于2026年10月20日和21日尝试利用其实例中的该漏洞,但未能成功。攻击者发送了专门构造的CI配置,并让工作进程崩溃了八次。其中四次,利用在下一步失败。攻击者还下载了Alpine的GitLab容器镜像。10月25日和26日的新尝试已被拦截。
Alpine的维护人员表示,“The attack came close to working”。他们补充说,没有发现攻击成功的证据,但无法排除这种可能,因此从零重建了该实例。据他们称,aports仓库、软件包以及10月21日的发布版本均未被篡改。
哪些版本受到影响?
对于CVE-2026-97229,GitLab列出的受影响范围包括19.2修复前的所有版本、19.3修复前(即19.3.5之前)的版本,以及19.4修复前(即19.4.2之前)的版本。GitLab.com已经运行修复后的版本。GitLab Dedicated租户在公开发布前已通过内部版本完成更新。
GitLab还指出,19.3.4在启用Ona集成时,合并请求页面存在一个缺陷,该问题已在19.3.5中修复。此外,公司还发布了六条威胁检测规则,帮助自行托管实例的管理员识别利用尝试。
同一补丁中的其他漏洞
此次发布不仅包含最严重的那一个漏洞。以下是其他修复,评分均来自GitLab公布的数据。
- CVE-2026-92883,语法高亮中的跨站脚本,CVSS 8.7。
- CVE-2026-16301,Developer角色用户可在受保护分支上启动流水线,CVSS 8.5。
- CVE-2026-14814,原始文件缓存投毒,可能导致受保护变量泄露,CVSS 8.2。
- CVE-2026-81839,项目转移到新群组后,流水线以新群组的权限运行(仅限企业版),CVSS 7.7。
- CVE-2026-96893,GitLab Duo AI代理指令注入(仅限企业版),CVSS 7.3。
此外还有五个中等严重程度的漏洞,包括通过GraphQL读取私密备注,以及GitLab Pages日志中的令牌泄露。完整列表请参阅官方页面。
需要了解的局限
我们不知道有多少实例已被攻陷。BleepingComputer引用的Shadowserver统计到近2800个暴露在互联网上的社区版实例,但没有说明其中有多少已经更新。这个数字不应被理解为存在漏洞的系统数量。
现有资料没有说明攻击者是谁,也没有说明除Alpine之外是否还有其他案例。漏洞的技术细节尚未公开。GitLab会在补丁发布90天后公开报告,因此更多细节可能随后出现。
对数字工作者意味着什么
如果您的工作室或公司使用自行托管的GitLab,首要任务是版本更新。在包含代码、机密和流水线的服务器上存在无需认证的漏洞,对客户来说也是实际风险。将代码托管在GitLab.com上的用户,平台层面已经得到保护。
Alpine的经验很实际,如果无法排除入侵的可能,就重建实例并轮换机密。自动化部署有助于此,我们在关于Ansible配置与部署的指南中有详细介绍。服务器还需要严格的更新纪律,我们在Fragnesia和PHP2Shell的报道中也讨论过这一点。补丁发布后出现扫描的另一个近期案例是Oracle E-Business Suite。如果您没有时间跟进这些内容,还可以选择提供安全更新的托管主机和服务器。
我们的看法
此案例显示,从补丁发布到遭受攻击的时间窗口非常短。修复于10月12日发布,Alpine的尝试始于10月20日,间隔仅八天。如果等到下一个月度更新周期再升级,就已经来不及了。
但也有一点需要保持警惕。据称GitLab被超过半数的《财富》100强企业使用,而BleepingComputer列出了同期一系列最高级别的漏洞,其中还有另外两个最高严重程度的漏洞。对于保管企业代码和机密的服务来说,这样的频率值得重视。仅仅说GitLab修复速度快是不够的,即使它确实很快。选择自建的团队必须做好持续防护的准备,否则就应交给专业团队来负责。
常见问题
我需要立即更新GitLab吗?
是的,如果您的实例是自行托管且版本在上述范围内。GitLab建议立即升级到19.4.2、19.3.5或19.2.8。CISA已确认该漏洞正被积极利用。
GitLab.com有风险吗?
根据GitLab的说法,没有风险。GitLab.com已经运行修复后的版本,Dedicated租户也在公开发布前完成了更新。
利用该漏洞需要账户吗?
不需要。CVSS向量显示无需任何权限,也无需用户交互。攻击通过一份精心构造的CI/CD配置实施。
如何判断自己是否遭到攻击?
现有资料中没有确定的方法。GitLab为自行托管实例发布了六条检测规则。Alpine在出现异常CI配置后,观察到工作进程反复崩溃。
仅仅更新就够了吗?
视情况而定。如果实例在前几天处于暴露状态且未打补丁,就不能排除已被入侵的可能。Alpine选择了从零重建。
未来几周需要关注什么,兼顾补丁与检查
未来几天的关键是弄清楚除Alpine之外是否还会出现其他案例,以及是否会公布技术细节。以下三点建议供参考。
- 将您所用分支更新到最新可用版本,并在安装后核对版本号。
- 利用GitLab的检测规则,检查工作进程的日志是否有反复崩溃以及异常的CI配置。
- 如果实例曾暴露且未更新,请轮换令牌和受保护变量,并考虑重建实例。




