CVE-2026-97229 排查：GitLab 自建实例，版本和 Ruby 一起核
GitLab 一个 CVSS 满分（10 分）的漏洞 CVE-2026-97229 已确认在野利用。自建实例先核版本，升到对应修复版；自带 Ruby 环境的，Ruby 也要一起升。
满分漏洞进了在野名单，窗口以天计
SecurityWeek 报道（2026 年 10 月 30 日），代码托管平台 GitLab 的 CVE-2026-97229 正式进入"确认在野利用"的名单：CVSS 评分 10 分（满分口径），根因出在 Ruby 的正则表达式引擎 Onigmo 上。GitLab 在 10 月 12 日发布公告，受影响的是自建的社区版与企业版——19.2、19.3、19.4 三条版本线，分别升到 19.2.8、19.3.5、19.4.2 才算修复。在野利用已经有实打实的案例：开源发行版 Alpine Linux 的 GitLab 实例，在 10 月 20 日、21 日遭到攻击——距漏洞披露只过了一周。这次攻击没有得手，Alpine 公开说明代码仓库和软件包未发现被篡改，但仍然把整个实例推倒重建、重置了全部口令——因为他们无法排除攻击者真的在服务器上执行过代码，这个防御姿态值得抄。官方机构的跟进也很快：10 月 29 日，美国网络安全机构 CISA 把这个漏洞收进"已知在野利用漏洞目录"，给联邦机构定的处理限期只有三天。
容易漏的一条：根因在 Ruby，光升 GitLab 不一定够
这个案例里容易被忽略的一条，藏在 Alpine 的事件说明里：漏洞根因在 Ruby 引擎，不在 GitLab 本身。这意味着，如果企业的 GitLab 是源码安装、或者跑在自建的容器镜像里（用的是自己的 Ruby），光把 GitLab 升到修复版还不够——Ruby 本身也要升到 3.3.13、3.4.12、4.0.9 或更高版本；用官方安装包和官方镜像的，升级 GitLab 即可覆盖。“升级了还是带洞”，正是这类供应链型漏洞的典型形态：修应用，还要修它脚下的依赖。
排查清单，照着走一遍
- 先查有没有自建 GitLab——研发团队管代码的单位几乎都有；
- 有，就核版本，低于 19.2.8、19.3.5、19.4.2 的按对应版本线升级；
- 自带 Ruby 的把 Ruby 一起核；
- 确认 GitLab 的管理入口有没有暴露在公网，能收进内网就收；
- 顺手翻一遍账号列表，清掉来历不明的新注册用户和闲置账号；
- 升级前照例先把数据备份导出；
- 升完别急着收工，看一眼服务日志，确认 GitLab 起来之后一切正常。
没自建 GitLab、用的是托管服务的单位，这条漏洞不用慌——但这张清单的思路是通用的：任何一个研发工具，都值得说清楚它跑的什么版本、脚下的依赖是什么、管理口开在哪。
信息来源：SecurityWeek 报道（2026 年 10 月 30 日）、GitLab 官方公告（10 月 12 日）、CISA 已知在野利用漏洞目录
满分漏洞进了在野名单，处理窗口从来以天计。贵州的企业需要把自建 GitLab、代码服务器这类研发资产核版本、清账号、收端口的，贵州诚鑫致达科技（企业数据管家）可以按清单上门盘一遍——补丁这件事，先核版本再动手。
想获得贴合自身场景的数据管理建议？联系我们，或浏览技术博客获取更多实战经验。
企业存储选型参考｜贵州诚鑫致达
做核心业务 SAN 存储与高可靠应用，群晖机型参考：UC3400 · UC3200 · SA3600。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。
服务区域｜贵州诚鑫致达
贵州群晖NAS、贵阳存储、数据备份、信创云盘或 IT 集成服务，可联系贵州诚鑫致达科技，服务范围覆盖贵州全省各市州。凯里（黔东南）、都匀（黔南）：企业存储方案与 IT 运维。
