--- title: "GitLab脆弱性の対応手順｜修正版19.4.2への更新と判断基準【2026年10月】" url: "https://www.issoh.co.jp/tech/details/18332/" published: 2026-10-14 updated: 2026-10-14 categories: ["開発"] publisher: "株式会社一創" --- # GitLab脆弱性の対応手順｜修正版19.4.2への更新と判断基準【2026年10月】 2026年10月12日、GitLabはCVSS 10.0の脆弱性CVE-2026-97229を含む24件を修正したクリティカルパッチ（19.4.2／19.3.5／19.2.8）を公開しました。GitLabの脆弱性は、Self-Managedで自社運用しているかどうかで対応がまったく変わります。この記事では、脆弱性情報を受け取る経路、自社インスタンスの版を調べて修正の要否を判定する手順、修正版へ上げるコマンドと適用後の確認、そして即日適用すべき条件と作業不要な条件を、公式ドキュメントの記載をもとに整理します。 ## まとめ：GitLab脆弱性は版の特定・修正版の選択・停止点の確認で片付く GitLab.comとGitLab Dedicatedの利用者に作業はありません。公式のパッチリリースは「GitLab.com is already running the patched version」と明記しており、Dedicatedも対応不要とされています。手を動かすのはSelf-Managedの管理者だけです。 Self-Managedなら、まず稼働中の版をAPIで取り、同じマイナー版の修正版と比べます。19.2・19.3・19.4のどれかなら、同じマイナー内のパッチ版へ上げるだけで済み、アップグレードの必須停止点は関係しません。19.1以前は修正版が出ない保守対象外の版なので、停止点を経由して19.2.8以上へ移る計画が要ります。 インターネットから到達できるインスタンスで19.2〜19.4を使っているなら、今回のパッチは当日中に当ててください。未認証で任意コード実行に至る脆弱性が含まれるためです。 ## GitLabの脆弱性情報を受け取る経路｜パッチリリースの周期とRSS・CVE公開の時期 GitLabの脆弱性は、個別の注意喚起ではなく「パッチリリース」の告知にまとめて載ります。受け取り方と周期を知っておくと、見落としが減ります。 ### 月2回の定例パッチと臨時のクリティカルパッチで出る修正版の種類 パッチリリースには2種類あります。毎月第2・第4水曜に出る定例リリースと、深刻度の高い脆弱性に対して臨時に出るクリティカルパッチです。2026年10月12日は月曜日で、後者にあたります。 新機能を含むマイナー版は[GitLabのリリース・保守ポリシー](https://docs.gitlab.com/policy/maintenance/)で毎月第3木曜と定められ、次のメジャー版20.0は2027年5月20日の予定です。同ポリシーでは、バグ修正は最新の安定版だけ、セキュリティ修正は最新版に加えて直前2つのマイナー版までさかのぼって提供されます。2026年10月14日時点の保守対象は19.4（バグとセキュリティ）、19.3と19.2（セキュリティのみ）でした。 ### RSS・メール通知・CVEリポジトリの3経路と公開されない事前告知 通知は[GitLabのセキュリティFAQ](https://about.gitlab.com/security/faq/)が案内する経路で受け取ります。手間が少ないのは[パッチリリースのRSSフィード](https://docs.gitlab.com/releases/patch-releases.xml)をチャットツールやRSSリーダーへ流す方法で、メールで受けたい場合はSecurity Noticesのメーリングリストに登録します。 - パッチリリースのRSS：修正版が出るたびに告知記事が1件追加される - Security Noticesメーリングリスト：同じ告知をメールで受け取る - [gitlab-org/cvesリポジトリ](https://gitlab.com/gitlab-org/cves)：GitLabがCNAとして採番したCVEの記録 同FAQによると、GitLabは顧客にセキュリティリリースの事前告知をしません。各脆弱性の詳細なissueが公開されるのは、修正を含むリリースから90日後です。告知の当日に読める情報は概要・影響版・CVSSだけで、攻撃手順の詳細は出ません。だからこそ影響版の判定と適用を、告知の当日に終わらせる体制が要ります。 ## 2026年10月12日のクリティカルパッチ｜CVE-2026-97229ほか24件の影響 今回の[GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)は、Critical 1件、High 5件、Medium 14件、Low 4件の計24件を修正しています。CE・EEの両方が対象です。 ### 未認証で任意コード実行に至るCVE-2026-97229の条件と影響版 CVE-2026-97229は、CI/CDの正規表現コンパイラにおける整数オーバーフローです。公式の説明では、特定の条件下で未認証のユーザーが、CI/CD設定内に細工した正規表現を置くことで、GitLabサーバー上で任意のコードを実行できるおそれがありました。原因は正規表現の検証不足とされています。 CVSS v3.1は10.0（AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）。ネットワーク越しに、認証なし・利用者の操作なしで、影響範囲がGitLab本体を超える評価です。ベクトルの各項目の読み方は[CVSSv3の計算式と評価基準](https://www.issoh.co.jp/tech/details/5094/)で解説しています。影響を受けるのは19.2.0〜19.2.7、19.3.0〜19.3.4、19.4.0〜19.4.1で、19.1以前はこのCVEの影響版に含まれません。 ### High 5件に含まれるDuo Agent Platformと実行ポリシーの欠陥 Highの5件は性質がばらばらです。使っている機能によって重みが変わるので、自社で有効にしている機能と突き合わせます。 | CVE | 内容 | CVSS | 影響の始まる版 | | -------------- | ---------------------- | ---- | ------- | | CVE-2026-92883 | シンタックスハイライトのXSS | 8.7 | 19.1 | | CVE-2026-16301 | 下流パイプライン作成の認可不備 | 8.5 | 18.7 | | CVE-2026-14814 | リポジトリファイル取得の正規表現不備 | 8.2 | 全版 | | CVE-2026-81839 | スケジュール型実行ポリシーの認可不備（EE） | 7.7 | 18.1 | | CVE-2026-96893 | Duo Agentの入力無害化不備（EE） | 7.3 | 19.1 | CVE-2026-96893は、エージェントに渡る入力の扱いに関する欠陥です。[GitLab Duo Agent Platformの機能と課金の仕組み](https://www.issoh.co.jp/tech/details/10660/)をすでに業務で使っているチームは、このパッチを先送りする理由がありません。CVE-2026-14814は影響版が全版とされているため、19.1以前の利用者も対象です。 ### 単一ノードで発生するダウンタイムとデプロイ後マイグレーションの扱い 今回のパッチにはデータベースのマイグレーションが含まれます。単一ノード構成では、マイグレーションが終わるまでGitLabが起動しないため、適用中にダウンタイムが発生する点に注意が要る構成です。マルチノード構成なら、ゼロダウンタイムアップグレードの手順に沿えば停止なしで当てられます。 19.3.5にはデプロイ後マイグレーションも含まれます。19.3系の利用者は、パッケージ適用の完了を作業終了とせず、後段のマイグレーションが走り終わるまで確認を続けてください。なお19.3.4には、Ona連携を有効にしているとマージリクエスト画面に不具合が出る問題があり、これも19.3.5で直っています。 ## 自社GitLabの版を調べて修正版の要否をAPIとシェルで判定する手順 脆弱性の告知を読んだら、最初にやるのは自社インスタンスの版の特定です。管理画面を開かなくても、APIで取れます。 ### バージョンAPIで稼働中の版とCE・EEの区別を取得するcurl例 [GitLabのMetadata API](https://docs.gitlab.com/api/metadata/)には `GET /version` があり、アクセストークンを付けて呼ぶと稼働中の版とEEかどうかが返ります。 ``` curl --request GET \ --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \ --url "https://gitlab.example.com/api/v4/version" # 応答例（公式ドキュメントの例） # {"version":"18.1.1-ee","revision":"ceb07b24cb0", ... ,"enterprise":true} ``` versionの末尾が「-ee」ならEnterprise Edition、「-ce」ならCommunity Editionです。今回の24件のうちCVE-2026-81839など一部はEEだけが対象なので、版番号と一緒にエディションも控えておきます。 ### 修正版判定スクリプトで19.2〜19.4の未適用インスタンスを洗い出す 複数のインスタンスを持つ組織では、版を目で比べる方法では見落としが出るのが実情です。次のスクリプトは、上のAPIで取った版を2026年10月12日の修正版と比べ、未適用なら終了コード1を返します。CIのスケジュールジョブに入れておけば、適用漏れが残っている間はジョブが失敗し続けます。 ``` #!/usr/bin/env bash # 2026-10-12 クリティカルパッチ（19.4.2 / 19.3.5 / 19.2.8）の適用有無を判定する GITLAB_URL="https://gitlab.example.com" VER=$(curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" "$GITLAB_URL/api/v4/version" | jq -r .version) VER=${VER%%-*} # 例: 19.3.4-ee を 19.3.4 にする MAJ=$(echo "$VER" | cut -d. -f1) MIN=$(echo "$VER" | cut -d. -f2) PAT=$(echo "$VER" | cut -d. -f3) case "$MAJ.$MIN" in 19.4) FIX=2 ;; 19.3) FIX=5 ;; 19.2) FIX=8 ;; *) echo "$VER: 今回の修正版の対象外。保守対象の版かをリリースノートで確認する"; exit 2 ;; esac if [ "$PAT" -ge "$FIX" ]; then echo "$VER: 修正済み" else echo "$VER: 未修正。$MAJ.$MIN.$FIX 以上へ上げる"; exit 1 fi ``` 終了コード2は「判定対象外」を表します。19.1以前なら保守対象外の版、19.5以降なら新しいマイナー版です。どちらも人が[パッチリリースの影響版の記載](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)を読んで判断します。次の告知が出たら、case文の3行を新しい修正版の番号に書き換えて使い回せます。 ### 19.1以前と18系に残る版で経由が必要な必須停止点の数え方 19.2〜19.4の利用者は同じマイナー内のパッチ版へ上げるだけなので、停止点を気にする必要はありません。問題は19.1以前です。[GitLabのアップグレードパス](https://docs.gitlab.com/update/upgrade%5Fpaths/)では、17.5以降の必須停止点はx.2・x.5・x.8・x.11に置かれ、19系は19.2・19.5・19.8・19.11、18系は18.2・18.5・18.8・18.11です。 たとえば18.9で止まっているインスタンスは、18.11の最新パッチを経由してから19.2.8へ上げます。19.2.8から19.4.2へは、間に停止点（19.5）が無いので直接の更新が可能です。各停止点では、次へ進む前にバックグラウンドマイグレーションの完了を待つ必要があり、1回の作業枠で済まないことがあります。18.10から19.4への具体的な経路は[GitLab 18.10の保守終了と19.4への移行経路](https://www.issoh.co.jp/tech/details/11561/)で扱っています。 ## 修正版へ上げる作業手順｜バックアップ・移行確認・apt適用・適用後チェック ここではUbuntu上のLinuxパッケージ（Omnibus）で、19.3.4-eeを19.3.5-eeへ上げる場合を例にします。手順の出典は[Linuxパッケージのアップグレード手順](https://docs.gitlab.com/update/package/)と[アップグレード前の確認事項](https://docs.gitlab.com/update/plan%5Fyour%5Fupgrade/)です。 ### 適用前に残りの移行をSQLで確かめてバックアップを取るコマンド ``` # 1. 未完了のバッチ型バックグラウンドマイグレーションを確認（0行なら完了） sudo gitlab-psql -c "SELECT job_class_name, table_name, column_name, job_arguments FROM batched_background_migrations WHERE status NOT IN(3, 6);" # 2. 構成を確認 sudo gitlab-rake gitlab:check # 3. バックアップを取り、設定ファイル2点を別に退避 sudo gitlab-backup create sudo mkdir -p /root/gitlab-config-backup sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /root/gitlab-config-backup/ ``` 1のSQLは[移行状況の確認手順](https://docs.gitlab.com/update/background%5Fmigrations/)に載っているもので、0行が返れば前回のアップグレードの移行は終わっています。行が残っている状態で次の版へ進めないでください。 設定ファイル2点を別に退避するのは、[バックアップの公式手順](https://docs.gitlab.com/administration/backup%5Frestore/backup%5Fgitlab/)が、gitlab-backupの成果物とは別に保存するよう求めているためです。同じページには、バックアップは作成時とまったく同じ版・同じエディションのGitLabにしか復元できないとあります。戻す可能性があるなら、上げる前の版番号を必ず記録してください。 ### 版を指定してaptで修正版を入れる手順とRunnerを揃える順序 ``` # 4. 修正版を版指定で入れる（19.3系の例） sudo apt update sudo apt install gitlab-ee=19.3.5-ee.0 # 5. 適用後の確認 sudo gitlab-rake gitlab:check sudo gitlab-rake gitlab:doctor:secrets ``` 版を指定せずに `apt install gitlab-ee` とすると、その時点の最新版が入ります。19.1以前から上げる途中で使うと必須停止点を飛び越えるため、停止点を経由する作業では必ず版を指定します。Community Editionはパッケージ名をgitlab-ce、末尾を-ce.0に読み替えてください。 Linuxパッケージは、新しい版を入れる前にデータベースのバックアップを自動で取る仕様です。この自動バックアップは空ファイルskip-auto-backupを置くと省略できますが、公式は省略する場合でも自前の完全なバックアップを保つよう求めています。単一ノードの手順では、適用前にCI/CDのパイプラインとジョブを一時停止し、GitLab Runnerを対象と同じ版へ揃え、Premium以上ならメンテナンスモードの有効化も検討する流れになっています。 ### 適用後にUIとCI/CDで確かめる6項目と戻せなくなる失敗パターン コマンドが通っても、利用者側の操作が通るとは限りません。公式の確認項目から、実際に触って確かめる6つを抜き出します。 1. 利用者がサインインできる 2. プロジェクト一覧が表示される 3. Issueとマージリクエストが開ける 4. リポジトリをcloneできる 5. コミットをpushできる 6. Runnerがジョブを拾い、コンテナレジストリへのpushとpullが通る 戻せなくなる典型は、gitlab-secrets.jsonを失うことです。これが無いと、暗号化してデータベースに入れたCI/CD変数や2要素認証の設定を復号できません。適用後に `gitlab:doctor:secrets` で復号の可否を確かめるのはこのためです。 ## 適用の優先度を決める判断基準｜即日適用・計画適用・作業不要の切り分け 同じ告知でも、インスタンスの置き方と版によって急ぐ度合いが違います。今回のパッチを例に、3つに切り分けます。 ### インターネット公開のSelf-Managedで19.2〜19.4を使う場合は即日適用 外部から到達できるインスタンスで19.2〜19.4を使っているなら、告知の当日に適用します。CVE-2026-97229は未認証・利用者操作なしで成立する評価で、待つ理由になる条件がありません。単一ノードでダウンタイムが出る点は、業務時間外に回す理由にはなっても、翌週へ延ばす理由にはなりません。 VPNや社内ネットワークの内側だけで使っている場合も、計画適用でよいのは数日以内までと考えてください。社内の端末が1台でも侵害されれば、攻撃者は内側から同じ脆弱性を突けます。 ### 19.1以前に留まる環境は修正版が届かないため移行計画を先に立てる 19.1以前はCVE-2026-97229の影響版から外れますが、安心材料にはなりません。CVE-2026-14814（全版）やCVE-2026-16301（18.7以降）の影響は受け、しかも保守対象外のため修正版が出ません。この状態で取れる対応は、必須停止点を経由して19.2.8以上へ移ることだけです。 停止点ごとにバックグラウンドマイグレーションの完了待ちが入るため、18系前半からなら複数日の作業になることがあります。告知を待ってから計画するのでは遅く、保守対象の範囲（最新を含む3つのマイナー版）から外れる前に上げておく運用に切り替えるのが筋です。19.2で入った機能の範囲は[GitLab 19.2の新機能と提供ティア](https://www.issoh.co.jp/tech/details/15769/)で確認できます。 ### GitLab.comとDedicatedは作業不要でも確認したい自社管理のRunner GitLab.comとGitLab Dedicatedは、GitLab側で修正済み・対応不要と告知されています。ただし、GitLab.comに自社管理のGitLab Runnerをつないでいる場合、そのRunnerの更新は自社の担当です。Runnerの更新手順はパッチリリースの告知からも案内されているので、本体の告知を読むときにRunner側の記載も確かめてください。 ### パッチ適用を自社で回せない場合に保守契約で決めておく4つの範囲 Self-Managedの運用で詰まりやすいのは、告知を読む人と適用する人が決まっていない状態です。外部に任せるなら、契約で次の4点を決めておきます。告知を受けてから判定までの時間、Criticalを適用するまでの時間、必須停止点をまたぐアップグレードの扱い（定額か別見積もりか）、そしてバックアップとgitlab-secrets.jsonの保管責任です。 一創では、Webシステムの[保守運用・内製化支援](https://www.issoh.co.jp/service/system/maintenance/)として、パッチ適用の運用設計から、社内で回せるようにするための手順整備までを支援しています。 ## よくある質問：GitLabの脆弱性とセキュリティパッチ適用で迷う5つの論点 GitLabの脆弱性対応で、管理者から出やすい質問をまとめました。 ### GitLab.comを使っている場合も脆弱性への対応は必要ですか？ GitLab本体への作業は不要です。2026年10月12日のパッチリリースでも、GitLab.comはすでに修正版で稼働しており、GitLab Dedicatedも対応不要と明記されています。ただし、自社で管理しているGitLab Runnerは利用者側の管理物です。Runnerの版はRunner側の告知で確認してください。 ### 今使っているGitLabのバージョンはどこで確認できますか？ APIの `GET /api/v4/version` にアクセストークンを付けて呼ぶと、versionに版番号、末尾にceかeeが返ります。応答にはenterpriseという真偽値も含まれ、EEかどうかを直接判定できます。複数台を管理しているなら、APIで取って修正版と機械的に比べるほうが見落としません。 ### 修正版はいくつかのマイナー版に出ますが、どれを選べばよいですか？ 今使っているマイナー版と同じ系列の修正版を選びます。19.3を使っているなら19.3.5です。同じマイナー内のパッチ版への更新は必須停止点に関係せず、新機能も入らないため、検証範囲が最小で済みます。19.4へ上げるかどうかは、脆弱性対応とは切り離して判断してください。 ### 脆弱性の詳しい内容や攻撃手順はいつ公開されますか？ GitLabのセキュリティFAQでは、各脆弱性の詳細なissueは修正を含むリリースから90日後に公開されるとしています。告知の時点で分かるのは概要・影響版・CVSSまでです。事前告知もしない方針なので、告知が出た当日に判定と適用を始められる体制を用意しておく必要があります。 ### アップグレードに失敗したら元の版に戻せますか？ 戻せますが、条件付きです。バックアップは作成時とまったく同じ版・同じエディションにしか復元できないため、旧版のパッケージを入れ直してから復元します。gitlab-secrets.jsonとgitlab.rbはバックアップに含まれないので、別に退避していないと暗号化されたデータを読めなくなります。 ## 関連記事 - [GitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較](https://www.issoh.co.jp/tech/details/4219/)：Self-Managedで持つか、SaaSに寄せるかの判断材料になります - [CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化](https://www.issoh.co.jp/tech/details/5092/)：告知に並ぶCVE番号の読み方を押さえられます - [tj-actions/changed-files侵害（CVE-2025-30066）とreviewdog/action-setup侵害の経緯・影響確認・再発防止](https://www.issoh.co.jp/tech/details/6531/)：CI/CD基盤が狙われた事例と影響確認の手順です - [AWS運用保守の委託範囲と費用｜監視・障害対応・パッチ適用の判断基準](https://www.issoh.co.jp/column/details/16410/)：パッチ適用を委託するときの範囲と費用の決め方を扱います --- 出典: [GitLab脆弱性の対応手順｜修正版19.4.2への更新と判断基準【2026年10月】]()（株式会社一創）