2026.10.14 開発

GitLab脆弱性の対応手順｜修正版19.4.2への更新と判断基準【2026年10月】

Q: 今使っているGitLabのバージョンはどこで確認できますか？

APIの GET /api/v4/version にアクセストークンを付けて呼ぶと、versionに版番号、末尾にceかeeが返ります。応答にはenterpriseという真偽値も含まれ、EEかどうかを直接判定できます。複数台を管理しているなら、APIで取って修正版と機械的に比べるほうが見落としません。

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のリリース・保守ポリシーで毎月第3木曜と定められ、次のメジャー版20.0は2027年5月20日の予定です。同ポリシーでは、バグ修正は最新の安定版だけ、セキュリティ修正は最新版に加えて直前2つのマイナー版までさかのぼって提供されます。2026年10月14日時点の保守対象は19.4（バグとセキュリティ）、19.3と19.2（セキュリティのみ）でした。

RSS・メール通知・CVEリポジトリの3経路と公開されない事前告知

通知はGitLabのセキュリティFAQが案内する経路で受け取ります。手間が少ないのはパッチリリースのRSSフィードをチャットツールやRSSリーダーへ流す方法で、メールで受けたい場合はSecurity Noticesのメーリングリストに登録します。

パッチリリースのRSS：修正版が出るたびに告知記事が1件追加される
Security Noticesメーリングリスト：同じ告知をメールで受け取る
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は、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の計算式と評価基準で解説しています。影響を受けるのは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の機能と課金の仕組みをすでに業務で使っているチームは、このパッチを先送りする理由がありません。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には 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以降なら新しいマイナー版です。どちらも人がパッチリリースの影響版の記載を読んで判断します。次の告知が出たら、case文の3行を新しい修正版の番号に書き換えて使い回せます。

19.1以前と18系に残る版で経由が必要な必須停止点の数え方

19.2〜19.4の利用者は同じマイナー内のパッチ版へ上げるだけなので、停止点を気にする必要はありません。問題は19.1以前です。GitLabのアップグレードパスでは、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への移行経路で扱っています。

修正版へ上げる作業手順｜バックアップ・移行確認・apt適用・適用後チェック

ここではUbuntu上のLinuxパッケージ（Omnibus）で、19.3.4-eeを19.3.5-eeへ上げる場合を例にします。手順の出典はLinuxパッケージのアップグレード手順とアップグレード前の確認事項です。

適用前に残りの移行を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は移行状況の確認手順に載っているもので、0行が返れば前回のアップグレードの移行は終わっています。行が残っている状態で次の版へ進めないでください。

設定ファイル2点を別に退避するのは、バックアップの公式手順が、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つを抜き出します。

利用者がサインインできる
プロジェクト一覧が表示される
Issueとマージリクエストが開ける
リポジトリをcloneできる
コミットをpushできる
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の新機能と提供ティアで確認できます。

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システムの保守運用・内製化支援として、パッチ適用の運用設計から、社内で回せるようにするための手順整備までを支援しています。

よくある質問：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で取って修正版と機械的に比べるほうが見落としません。