GitLab CVE-2026-97229 安全排查与升级-TKMiss Notes

自托管 GitLab 只要运行在受影响版本，就先升级；单次 502 响应不能证明是否已被利用，还要核对 CI lint 请求、公共项目分支和工作进程异常。

按更严格的版本边界，19.2、19.3、19.4 系列分别升级到至少 19.2.8、19.3.5、19.4.2；GitLab.com 已运行修复版本，GitLab Dedicated 用户无需自行升级。另见：GitLab Security Incident: Attempted Exploitation of CVE-2026-97229。

我的 GitLab 需要立刻升级吗？

先核对实际运行版本。两份二手资料列出的受影响范围如下，最终仍应以 GitLab 官方安全公告为准：

版本系列	所列受影响范围	所列受影响范围	保守升级目标
19.2	早于 19.2.8	早于 19.2.8	19.2.8 或更高
19.3	早于 19.3.4	早于 19.3.5	19.3.5 或更高
19.4	早于 19.4.2	早于 19.4.2	19.4.2 或更高

两份资料对 19.3 的修复版本判定不同；还提到，19.3.4 的 Ona 集成存在已知问题，计划在 19.3.5 修复。因此，不要停在 19.3.4，优先升级到 19.3.5 或更新的受支持版本。

Omnibus 和 Docker 安装可分别用以下命令检查运行版本：

# Omnibus 安装
sudo gitlab-rake gitlab:env:info

# Docker 安装，容器名按实际替换
docker exec -it <gitlab-container> gitlab-rake gitlab:env:info

不要只看镜像标签、配置文件或包管理侧显示的版本，最终要确认正在提供服务的实例已经完成升级。Helm、Kubernetes 等部署方式应按对应官方升级文档确认实际运行的 release 或 chart 版本。

截至相关报道发布时，尚未确认 CVE-2026-97229 已被实际利用，但这不等于当前实例没有扫描或利用尝试，也不能代替日志排查。

CI lint 出现 502，是否说明已经被利用？

不是。502 只是调查线索，不是入侵结论。复现说明指出，特定利用请求可能以 HTTP 502 结束，因为工作进程在执行命令后崩溃；同一个状态码既不能证明命令执行成功，也不能证明没有执行。

HTTP 502

排查时需要交叉核对三个层次。首先是请求层，应在可疑时间窗内检查反向代理或网关访问日志、GitLab 服务日志中的 CI lint 请求、连续的 5xx/502，以及工作进程重启或崩溃记录。资料没有给出适用于所有部署方式的统一日志路径，因此应以本实例实际配置为准。

其次是仓库层，需要检查公共项目中近期新增或修改的 .gitlab-ci.yml、异常分支、推送账户，以及包含 UTF-8 字符的仓库路径。攻击者需要先具备向公共项目分支推送内容的权限，但触发请求本身可能不携带令牌、Cookie 或授权头；“触发请求未认证”并不代表前置写入条件不存在。

最后是主机与凭据层，应检查异常子进程、命令执行、异常出站连接、仓库或制品变更，以及 CI/CD 令牌、密钥和制品库凭据的异常使用。复现说明显示，命令可能以 git 账户执行，因此不能把影响范围缩小为一次 Web 工作进程崩溃。

Rapid7 曾在官方 GitLab CE 19.4.1 镜像上复现任意代码执行，相同输入在 19.4.2 上不再奏效。该复现结果可用于在隔离测试环境中验证版本，但不要在生产实例重放 PoC。

发现可疑请求后，先删分支还是先轮换凭据？

先保存证据，再完成升级并收敛暴露面，最后根据能否排除代码执行决定凭据处置范围。

先保存访问日志、服务日志、异常分支、提交记录、diff、推送账户和时间信息。不要先删除分支，否则可能丢失判断攻击入口和影响时间窗的线索。

随后完成版本升级，并收紧不必要的公网暴露和公共项目写入面。如果暂时无法升级，收紧不必要的公网暴露和公共项目写入面只能降低风险，不能替代补丁；所给资料也没有提供一个可通用关闭漏洞的实例开关或菜单路径。

如果无法排除代码执行，应将源码仓库、CI/CD 配置、令牌、密钥和制品视为可能受污染，轮换相关凭据，并检查构建与发布产物。复现说明提到命令以 git 账户运行，这一身份可能接触代码及 CI/CD、密钥和制品库凭据。仅升级一个 GitLab 进程或重启容器不足以完成事件处置；安全公告还包含其他修复项，需要完整核对补丁说明。