mcpField
F
fix-gitlab-vuln

fix-gitlab-vuln

github.com/cognitionai安全1011 次安装6 天前更新
代码仓库

关于 fix-gitlab-vuln

fix-gitlab-vuln 是面向管理自托管 GitLab 的 Agent 修复技能，用于处理受 CVE-2026-110264 影响的部署。它先只读盘点部署代码并等待审批，再更新获批的 IaC，并准备包含发布安排和部署后检查的 PR。

主要功能

  1. 01只读盘点 GitLab 部署配置
  2. 02分类部署的漏洞状态
  3. 03选择并确认修复版本或 Chart
  4. 04验证部署配置
  5. 05准备包含停机和部署后检查的 PR

适用场景

  1. 01从基础设施仓库查找自托管 GitLab 版本
  2. 02修补获批的 Omnibus、Docker、Helm 或源码部署
  3. 03为旧版实例规划所需升级路径
  4. 04准备 GitLab 发布的验证步骤

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/cognitionai/devin-vuln-fixes --skill fix-gitlab-vuln

安装后在 Claude Code 中输入/fix-gitlab-vuln确认已加载。

详细介绍

修复 GitLab 漏洞（CVE-2026-110264，2026 年 10 月 21 日关键补丁）

概述

查找并修复受 CVE-2026-110264 影响的自托管 GitLab 实例。这是一个 CVSS 10.0 级、无需身份验证即可远程执行代码的漏洞，由 Onigmo 正则表达式编译器中的整数溢出导致，影响从 7.0 开始的所有 CE/EE 版本。已修复的版本：19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10 和 18.11.13。同一补丁版本还修复了 2 个高危、6 个中危和 4 个低危问题，并包含 10 月 8 日针对 CVE-2026-97229 的修复（CVSS 10.0，已在 19.4.2/19.3.5/19.2.8 中修复）。GitLab.com 和 GitLab Dedicated 已完成修补，因此本操作手册仅适用于自托管安装。先以只读方式盘点。编辑前请等待批准。修补部署 GitLab 的 IaC，验证运行版本，并创建范围明确的 PR。

需要用户提供的信息

  • 存放 GitLab 基础设施代码的仓库或组织（Helm values、Terraform、Ansible、Compose、Packer）。默认：用户指定的仓库，或 Agent 可访问的所有仓库。
  • 用户运行的是 GitLab.com、GitLab Dedicated 还是自托管实例；如果是自托管实例，还需提供实例 URL。
  • 批准要修补的部署，并为单节点实例提供维护窗口。

流程

  1. 在克隆之前，使用 Git 托管平台的代码搜索功能，以只读方式搜索所有可访问的仓库（如果没有代码搜索功能——这在 GitHub Enterprise Server 和自托管 GitLab 中很常见——则进行浅克隆，并运行 rg -n --hidden --glob '!.git'）。查找：
    • gitlab/gitlab-ee 和 gitlab/gitlab-ce 镜像，以及 CNG 镜像（registry.gitlab.com/gitlab-org/build/cng/*）。
    • gitlab Helm chart（charts.gitlab.io）和 GitLab Operator。
    • Ansible/Chef/Puppet/cloud-init/Packer 中的 gitlab-ee/gitlab-ce Omnibus 软件包。
    • 部署 GitLab 的 Terraform 模块和 AMI。
    • 源码安装（gitlab-foss/gitlab 检出）。
  2. 生成一张清单表，列出：仓库、文件:行号、部署类型（Omnibus、Docker、Helm、Operator、源码）、版本、当前版本或 chart 版本、精确/浮动固定方式、节点拓扑（单节点或多节点）以及置信度。单独列出无法搜索的仓库。如果用户使用 GitLab.com 或 Dedicated，则说明无需采取任何操作并停止。
  3. 将每项标记为已修复、易受攻击或未知。如果实例 URL 可访问，则与 /help 或 /api/v4/version 的结果进行比较（需要令牌）。否则依据固定的版本判断。
  4. 停止。展示表格，标出升级时会发生停机的单节点实例，并询问用户要修补哪些部署。在此发现阶段不要做任何更改。
  5. 逐个处理获批的部署。如果你的 Agent 支持子 Agent，则每个仓库运行一个，最多同时运行五个。编辑前，重新核对该仓库的清单。
  6. 对每个仓库，选择同一 minor 版本中已修复的补丁版本，并在编辑前确认该版本存在。当公共主机受阻时，检查仓库 CI 已使用的镜像仓库或软件包镜像（Artifactory、Nexus、Harbor 或云镜像仓库）；如果两者都无法访问，则在 PR 中将目标版本标记为未经验证，并由 CI 构建来验证。
    • Docker：gitlab/gitlab-ee:<ver>-ee.0 或 gitlab/gitlab-ce:<ver>-ce.0。如果按摘要固定，则解析并固定新的摘要。
    • Helm/Operator：在 https://docs.gitlab.com/charts/installation/version_mappings/ 查询 chart 版本（例如，GitLab 19.5.1 对应 chart 10.5.1，GitLab 18.11.13 对应 chart 9.11.14）。如果该页面无法访问，则针对 chart 仓库或集群使用的镜像运行 helm search repo gitlab/gitlab -l。升级 chart 版本，而不只是 global.gitlabVersion。
    • Omnibus：在配置管理代码中固定 gitlab-ee=<ver>-ee.0（或对应的 CE 版本）。
    • 源码：检出已修复的标签，并遵循目标版本的源码升级指南。
  7. 如果当前版本落后一个以上的 minor 版本，或处于不受支持的分支，则报告所需的升级路径中间步骤（https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/），不要跳跃升级。只有获得用户批准后，才能进行多步升级。
  8. 在每个 PR 中添加发布说明：
    • 升级前备份。
    • 单节点实例需要停机，因为 GitLab 启动前必须完成迁移。
    • 多节点实例的零停机流程。
    • 部署后迁移。
  9. 在不访问生产环境的情况下，尽可能进行验证：helm template/helm lint、terraform validate/plan、ansible-lint 和 Compose 配置检查。列出供用户运行的部署后检查：
    • gitlab-rake gitlab:env:info 显示已修复的版本。
    • gitlab-rake gitlab:check。
    • gitlab-ctl status，或 Helm 上的 Pod 就绪状态。
    • 后台迁移已完成。
    • Web、通过 SSH 和 HTTPS 的 Git，以及 CI 运行器均正常工作。
  10. 每个仓库单独开一个范围明确的 PR，列出每项部署的变更前 → 变更后、chart/镜像/软件包版本、摘要、升级路径说明、停机预期、验证结果以及部署后检查清单。
  11. 将各仓库的结果汇总到一张表中：仓库、PR、部署类型、变更前 → 变更后、停机情况、验证、受阻事项、后续工作。提醒用户，变更部署之前，实例仍然易受攻击。

规格

  • 发现过程为只读，并在明确的审批关口结束。
  • 确认每个目标镜像、图表或软件包存在后，才能进行编辑。
  • 每个 PR 都要说明停机影响，并附上部署后的验证清单。
  • 完成意味着每个获批部署都有一个 PR，或已报告为受阻并给出明确的下一步。

建议和提示

  • 可通过互联网访问的实例优先级最高，因为此漏洞无需身份验证即可利用。
  • GitLab 为自托管实例发布了两项威胁检测：“Onigmo native worker crash”和“Org mode render error burst”。请安全团队关注这些检测，以便查找此前的利用行为。
  • GitLab Runner 和 GitLab Agent 的版本单独管理，且未列入本安全公告。请勿将它们作为此次修复的一部分进行升级。
  • Geo 辅助节点以及多节点安装中的每个节点都必须运行相同版本。

禁止的操作

  • 用户批准部署前，不得进行编辑。
  • 不得猜测镜像标签、图表版本或软件包版本。
  • 不得跳过所需的升级路径步骤，也不得告知用户跳过迁移。
  • 不得更改版本类型（CE↔EE）或部署类型。
  • 不得对生产环境中的 GitLab 实例运行命令。

评论

支持 Markdown