mcpField
F
fix-gitlab-vuln

fix-gitlab-vuln

github.com/cognitionaiセキュリティ1011 回インストール6 日前に更新
リポジトリ

fix-gitlab-vuln について

fix-gitlab-vulnは、CVE-2026-110264の影響を受けるセルフマネージドGitLabを扱うエージェント向けの修正スキルです。変更せずに導入コードを調査して承認を待ち、その後、承認済みのIaCを更新し、展開手順と事後確認を含むPRを準備します。

主な機能

  1. 01GitLab導入構成の読み取り専用調査
  2. 02導入環境の脆弱性状態の分類
  3. 03修正版やチャート版の選定と確認
  4. 04導入設定の検証
  5. 05停止時間と事後確認を記したPRの準備

活用シーン

  1. 01インフラリポジトリからセルフマネージドGitLabの版を特定
  2. 02承認済みのOmnibus、Docker、Helm、ソース導入を修正
  3. 03古い環境に必要なアップグレード経路を計画
  4. 04GitLab展開の検証手順を準備

インストール

コマンドをコピーしてターミナルで実行します。

$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 インスタンスを特定し、パッチを適用します。これは、Onigmo 正規表現コンパイラーの整数オーバーフローによって引き起こされる、CVSS 10.0 の認証不要の RCE であり、バージョン 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 です。同じパッチリリースでは、High 2 件、Medium 6 件、Low 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）を格納しているリポジトリまたは組織。デフォルトでは、ユーザーが指定したリポジトリ、またはエージェントがアクセスできるすべてのリポジトリが対象です。
  • ユーザーが 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 チャート（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、ソース）、エディション、現在のバージョンまたはチャートバージョン、固定／浮動指定、ノード構成（単一ノードか複数ノードか）、信頼度をまとめたインベントリ表を1つ作成します。検索できなかったリポジトリは別に列挙します。ユーザーが GitLab.com または Dedicated を利用している場合は、対応不要であることを伝えて終了します。
  3. 各エントリに修正済み、脆弱、または不明のいずれかを付けます。インスタンス URL にアクセスできる場合は、/help または /api/v4/version の結果（トークンが必要）と比較します。それ以外の場合は、固定されたバージョンを基準にします。
  4. 終了します。表を提示し、単一ノードのインスタンスでダウンタイムが発生することを明記して、どのデプロイを修正するかユーザーに確認します。調査中は何も変更しません。
  5. 承認されたデプロイを1つずつ進めます。エージェントがサブエージェントに対応している場合は、リポジトリごとに1つ実行し、同時実行は最大5つまでとします。編集する前に、各リポジトリについてインベントリを再度作成します。
  6. 各リポジトリについて、同じマイナーバージョン内の修正済みパッチを選び、編集前にその存在を確認します。公開ホストにアクセスできない場合は、リポジトリの 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/ で調べます（例：GitLab 19.5.1 はチャート 10.5.1、GitLab 18.11.13 はチャート 9.11.14 です）。このページにアクセスできない場合は、クラスタが使用するチャートリポジトリまたはミラーに対して helm search repo gitlab/gitlab -l を実行します。global.gitlabVersion だけでなく、チャートバージョンを更新します。
    • Omnibus：構成管理コードで gitlab-ee=<ver>-ee.0（または CE 相当）を固定します。
    • ソース：修正済みタグをチェックアウトし、対象バージョンのソースアップグレードガイドに従います。
  7. 現在のバージョンが1つを超えるマイナーバージョン分遅れている場合、またはサポート対象外のブランチを使用している場合は、いきなりアップグレードするのではなく、必要なアップグレード経路上の停止ポイント（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 を1つ作成します。
  11. リポジトリごとの結果を、リポジトリ、PR、デプロイ種別、変更前 → 変更後、ダウンタイム、検証、未解決項目、フォローアップをまとめた1つの表に集約します。変更がデプロイされるまで、インスタンスは脆弱な状態のままであることをユーザーに伝えます。

仕様

  • 検出は読み取り専用で行い、明示的な承認ゲートで終了します。
  • 編集前に、対象となるすべてのイメージ、チャート、パッケージが存在することを確認します。
  • 各 PR には、ダウンタイムへの影響を明記し、デプロイ後の検証チェックリストを含めます。
  • 完了とは、承認されたすべてのデプロイに PR がある、または具体的な次の手順とともにブロック中であることを報告済みの状態を指します。

アドバイスと参考情報

  • インターネットからアクセス可能なインスタンスを最優先にします。このバグは認証なしで悪用可能なためです。
  • GitLab は、セルフマネージドインスタンス向けに 2 つの脅威検出を公開しています。「Onigmo native worker crash」と「Org mode render error burst」です。セキュリティチームにこれらを案内し、過去の悪用がないか調査してもらってください。
  • GitLab Runner と GitLab Agent は個別にバージョン管理されており、この勧告の対象には含まれていません。この修正の一環としてアップグレードしないでください。
  • Geo セカンダリと、マルチノード構成のすべてのノードは、同じバージョンで稼働させる必要があります。

禁止事項

  • ユーザーがデプロイを承認する前に編集しないでください。
  • イメージタグ、チャートのバージョン、パッケージのバージョンを推測しないでください。
  • 必須のアップグレード経路上のステップを省略したり、マイグレーションを省略するようユーザーに伝えたりしないでください。
  • エディション（CE↔EE）やデプロイの種類を変更しないでください。
  • 本番の GitLab インスタンスに対してコマンドを実行しないでください。

コメント

Markdown 対応