GitLab 19.2.1/19.1.3/19.0.5セキュリティリリース - Workhorse情報漏えいとPipeline Schedule APIのmass-assignmentなど13件のCVEを修正

GitLabは2026年7月29日、Community Edition(CE)とEnterprise Edition(EE)向けに19.2.1・19.1.3・19.0.5のパッチリリースを公開しました。今回の修正には合計13件のCVEが含まれ、うち3件がHigh、9件がMedium、1件がLowに分類されています。最も深刻なのは、GitLab Workhorseに存在する機微情報漏えいの脆弱性CVE-2026-6267で、CVSSスコアは8.5です。

GitLab.comを使うSaaS利用者はすでにパッチ適用済みで対応不要ですが、Self-managed環境を運用している場合は自分たちで更新作業が必要です。本記事では、GitLab公式のパッチリリースノート(docs.gitlab.com)を一次情報として、13件のCVEの内容、特に注意すべき3件の技術的な仕組み、自分の環境が影響を受けるかの確認手順、そして今後の運用上の教訓を整理します。CI/CDパイプラインを狙った攻撃という文脈では、以前に扱ったTanStackのnpmサプライチェーン攻撃事件とも通じる部分があります。

リリース概要(早見表)

GitLabのパッチリリースには、毎月第2・第4水曜に出る定例リリースと、深刻な脆弱性向けの臨時リリースの2種類があります。今回は定例枠での公開です。脆弱性の詳細Issueは、公開から90日後にGitLabのIssueトラッカーで一般公開される運用になっています。

13件のCVE一覧

公式リリースノートに掲載されている13件を、深刻度が高い順にまとめます。

CVE番号のプレフィックスが1件だけ「2025」になっている点(CVE-2025-14562)は誤記ではありません。CVE IDは採番と公開のタイミングがずれることがあり、2025年に採番されたCVEが2026年のリリースで修正されるケースはGitLabに限らず珍しくありません。

なお13件のうち9件はHackerOneのバグバウンティプログラム経由の外部報告、4件はGitLab社員による社内発見です。外部リサーチャーからの報告と内部の脆弱性診断の両輪で見つかっている点は、継続的なセキュリティレビュー体制の目安として押さえておく価値があります。

特に注意すべき3件の技術的解説

CVE-2026-6267: Workhorseの機微情報漏えい(CVSS 8.5)

何が起きるか: GitLab WorkhorseはNginxとRailsアプリケーションの間に立つGoで書かれたリバースプロキシで、大容量ファイルのアップロード処理やGit操作のストリーミングなどを担っています。今回の脆弱性は、Workhorseの内部リクエスト処理におけるアクセス制御の不備により、条件がそろうとDeveloperロールを持つ認証済みユーザーが本来アクセスできないはずの情報を取得できてしまうというものです。

CVSSベクタ: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H(スコア8.5)。ネットワーク経由(AV:N)で攻撃可能ですが攻撃条件は複雑(AC:H)、低権限(PR:L)のアカウントがあれば攻撃者操作(UI:N)なしに実行でき、Scope変更(S:C)を伴い機密性・完全性・可用性のすべてに高い影響(C:H/I:H/A:H)が及びうる、という組み合わせです。

前提条件: 攻撃者はDeveloperロール以上のアカウントを持つ認証済みユーザーである必要があります。完全な未認証攻撃ではありませんが、多くの組織でDeveloperロールは比較的広く付与されているため、内部関係者や侵害されたアカウントを起点とするリスクとして軽視できません。

実際の攻撃シナリオ: WorkhorseはRails側で本来チェックされるべき認可判断を経由せずに内部リクエストをバックエンドへ中継する場面があります。攻撃者はDeveloperロールのアカウントで、細工したリクエストをWorkhorse経由で送ることにより、他プロジェクトの内部情報やアクセス権限外のデータを間接的に取得できる可能性があります。HackerOne経由でthwin_htet氏から報告されました。

CVE-2026-12436: Pipeline Schedule APIのmass-assignment(CVSS 8.4)

何が起きるか: GitLabのPipeline Schedule API(CI/CDの定期実行スケジュールを設定するAPI)に、ユーザー入力の属性検証が不十分なmass-assignment(過剰代入)の欠陥がありました。これにより、認証済みユーザーが本来自分が所有していないパイプラインスケジュールのCI/CD設定を改変できる可能性があります。

CVSSベクタ: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L(スコア8.4)。CVE-2026-6267と同様にネットワーク経由・低権限アカウント・Scope変更を伴いますが、可用性への影響はLow(A:L)に留まる点が違いです。

前提条件: 低権限(PR:L)の認証済みアカウントが必要です。パイプラインスケジュール機能自体にアクセスできるプロジェクトメンバーであれば、条件を満たす可能性があります。

実際の攻撃シナリオ: mass-assignmentは、APIがリクエストボディの属性をそのままモデルへ代入してしまい、本来クライアントから変更させるべきでない属性(所有者ID、実行対象ブランチ、変数の内容など)まで書き換えられてしまう典型的な脆弱性パターンです。CI/CDパイプラインのスケジュール設定は、.gitlab-ci.ymlの実行内容や環境変数、デプロイ先を左右するため、ここが不正に書き換えられると、意図しないコードの実行やCI/CD変数(シークレットを含みうる)の露出につながる可能性があります。HackerOne経由でa0xnirudh氏から報告されました。CI/CDパイプラインを乗っ取る手口という点では、GitHub Actionsのキャッシュ汚染とOIDCトークン抽出を組み合わせたTanStack事件とも問題領域が近く、「CI/CD設定を誰がどこまで書き換えられるか」というアクセス制御の設計がいかに重要かを改めて示しています。

CVE-2026-15975: マージリクエストディスカッションのDoS(CVSS 7.5)

何が起きるか: マージリクエストのディスカッション(コメントスレッド)処理において、リソースのスロットリング(流量制御)が不足しており、未認証のユーザーがサービス拒否(DoS)を引き起こせる可能性があります。

CVSSベクタ: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H(スコア7.5)。攻撃条件は低い(AC:L)うえに権限不要(PR:N)、つまり未認証でネットワーク経由から実行可能という点が、この3件の中でも特に警戒すべきポイントです。機密性・完全性への影響はなく(C:N/I:N)、可用性への影響のみ高い(A:H)という、典型的なDoS型のベクタです。

前提条件: 認証は不要です。マージリクエストのディスカッション機能へアクセスできる(多くの場合、パブリックプロジェクトであれば匿名でも到達しうる)ことが条件です。

実際の攻撃シナリオ: 大量または巨大なディスカッション関連リクエストを連続で送りつけることで、サーバー側のリソース(CPU、メモリ、DB接続など)を消費させ、正規ユーザーのアクセスに支障をきたす可能性があります。GitLab社員のHordur Freyr Yngvason氏が社内で発見しました。DoSの一般的な緩和策(レート制限、リクエストサイズ上限、負荷分散)についてはレート制限アルゴリズムの解説記事でも扱っています。

その他10件の概要

残る10件はMedium 9件・Low 1件で、緊急性は前述の3件ほど高くありませんが、放置してよいわけではありません。傾向で分類すると次の3グループに整理できます。

アクセス制御・認可系(6件): CVE-2026-13113(マージリクエスト承認ルールの競合状態。承認なしで保護ブランチへマージされうる)、CVE-2026-16553(Virtual Registriesの認証情報が意図しないホストへ渡りうる)、CVE-2026-6336(プロジェクトインポート状況の閲覧権限不備)、CVE-2026-14341(Maintainerロールが保護ブランチ設定を不正に変更しうる)、CVE-2026-14351(非公開Issueのタイトルが未認証でも公開マージリクエスト経由で閲覧できてしまう)、CVE-2026-4672(Guestロールがテストレポートの内容を閲覧できてしまう)です。いずれも権限モデルの境界を越えてしまうパターンで、OAuth2/OIDCの認可フロー解説記事で扱っている「認証と認可は別レイヤーである」という原則がそのまま当てはまります。

AI機能(Duo)系(2件): CVE-2026-15077(Duo Code Reviewのプロンプトインジェクションにより、未認可プロジェクトの情報へアクセスされうる)、CVE-2026-15831(Duo Workflowsのセキュリティトークン生成不備により、管理者が設定したツールガバナンスポリシーを回避されうる)です。AIアシスト機能が権限境界の外側で情報を扱う設計になっていないかは、今後も継続的にチェックすべき領域です。

その他(2件): CVE-2026-3093(ページネーション画面でのXSS)、CVE-2025-14562(メンバーから外れた後もマージリクエストの共同編集設定経由でコミットできてしまう認可不備)です。

自分の環境が影響を受けるか確認する手順

GitLab.com(SaaS)利用者

対応は不要です。GitLab.comは公式リリース時点ですでにパッチが適用されています。GitLab Dedicatedの利用者も同様に対応不要です。

Self-managed利用者: まずバージョンを確認する

自前でホストしているGitLabインスタンスが対象バージョンかどうかを確認します。確認方法はいくつかあります。

管理者権限でログインし、Admin Area(管理者エリア)のダッシュボードでバージョンを確認する方法が最も手軽です。

APIから確認する場合は、アクセストークンを用意して次のように叩きます。

curl --request GET \
  --header "PRIVATE-TOKEN: <アクセストークン>" \
  --url "https://gitlab.example.com/api/v4/metadata"

レスポンスのversionフィールドに、稼働中のバージョンとエディション(例: 19.1.2-ee)が含まれます。

Omnibusパッケージでインストールしている場合は、サーバー上で次のコマンドでも確認できます。

sudo gitlab-rake gitlab:env:info

DockerやHelm chartで運用している場合は、使用しているイメージタグ(例: gitlab/gitlab-ee:19.1.2-ee.0)を確認してください。

確認したバージョンが、次のいずれかの範囲に該当すれば影響を受けます。

• 19.0系で19.0.5未満
• 19.1系で19.1.3未満
• 19.2系で19.2.1未満
• それより古い19.0未満のバージョン全般(各CVEの影響開始バージョンより新しいもの)

アップグレード手順

対象バージョンに該当した場合、次の順序で進めます。

1. アップグレードパスの確認: GitLab公式のアップグレードパスツール(Upgrade Path)で、現行バージョンから19.2.1・19.1.3・19.0.5のいずれかへ直接、または中間バージョンを経由して上げられるか確認します。メジャー・マイナーバージョンを飛ばす場合は、必須の中間バージョンが存在することがあります。
2. ダウンタイムの計画: 今回のパッチはDBマイグレーションを含みます。シングルノード構成では、マイグレーション完了までGitLabが起動しないためダウンタイムが発生します。マルチノード構成であれば、ゼロダウンタイムアップグレード手順を使うことで無停止での適用が可能です。
3. ステージング環境での検証: 可能であれば本番適用前にステージング環境でアップグレードを試し、post-deploy migration(19.2.1・19.1.3・19.0.5のいずれにも含まれる)が問題なく完了することを確認します。
4. 本番適用: パッケージマネージャ(apt/yum)、Docker、Helm chartなど、使用している方式に応じた標準の更新手順に従います。
5. Runner側の確認: GitLab Runnerを個別にバージョン管理している場合は、Runner自体は今回の脆弱性の直接対象ではありませんが、CI/CDパイプラインを扱う関連コンポーネントとして、あわせて最新の安定版を使っているか確認しておくと安全です。

今後の防御策・運用上の教訓

パッチリリースを定期購読する: GitLabは毎月第2・第4水曜に定例パッチをリリースしています。リリースブログの通知やRSSを購読し、公開から日を置かずに影響有無を判定できる体制を作っておくことが第一歩です。

mass-assignment対策としての属性allowlist: CVE-2026-12436が示すように、APIがリクエストボディの属性をそのままモデルに代入する設計は、意図しない属性の書き換えを許してしまいます。自社でAPIを開発する際も、更新可能な属性を明示的にallowlist化する(Railsで言えばstrong parameters相当の仕組みを徹底する)実装原則を再確認する価値があります。

ロールベースのアクセス制御を過信しない: 今回のCVEの多くは、Developer・Maintainer・Guestといった既存のロールの範囲内で、想定外の情報や操作にアクセスできてしまうというパターンでした。ロールが存在すること自体では防御にならず、各エンドポイント・各機能が意図通りに権限チェックを行っているかの継続的なレビューが必要です。

未認証DoSへの備え: CVE-2026-15975のように未認証・低コストで到達可能なDoSは、インターネットに公開しているSelf-managedインスタンスでは特にリスクが高くなります。WAFやリバースプロキシ側でのレート制限、異常なリクエストパターンの検知を、アプリケーション側の修正と合わせて多層で構えておくことが望ましいです。

CI/CD関連コンポーネントは特に優先度を上げる: Pipeline Schedule APIやPipeline Test Report APIのように、CI/CD設定やその結果に関わるコンポーネントの脆弱性は、単なる情報漏えいにとどまらず、ビルド・デプロイの改ざんに直結しうる領域です。自組織のGitLabインスタンスで、これらのAPIを使うワークフロー(自動デプロイ、外部通知連携など)がある場合は優先的に確認してください。GitとCI/CDの運用基盤を選ぶ観点はセルフホストGitサーバーの比較記事、日々のGit操作の効率化はGitコマンドとエイリアスまとめ、コミットメッセージの運用ルールはConventional Commitsガイドでも扱っています。同時期の他社のセキュリティリリースとしては、Next.jsの2026年7月セキュリティリリースも参考になります。

まとめ

• GitLabは2026年7月29日、19.2.1・19.1.3・19.0.5で計13件のCVE(High 3・Medium 9・Low 1)を修正しました。
• 最も深刻なのはWorkhorseの機微情報漏えいCVE-2026-6267(CVSS 8.5)。Developerロール以上の認証済みユーザーが本来アクセスできない情報を取得しうる脆弱性です。
• Pipeline Schedule APIのmass-assignment CVE-2026-12436(CVSS 8.4)は、CI/CD設定を他ユーザーが不正に改変できる可能性があり、CI/CDパイプラインの完全性に直結します。
• マージリクエストディスカッションのDoS CVE-2026-15975(CVSS 7.5)は未認証で悪用可能な点が特に注意を要します。
• GitLab.com(SaaS)・GitLab Dedicatedの利用者は対応不要ですが、Self-managed利用者はバージョンを確認し、該当する場合は早急にアップグレードしてください。
• シングルノード構成はダウンタイムを伴うため、メンテナンスウィンドウの確保が必要です。

参考リンク

• GitLab Patch Release: 19.2.1, 19.1.3, 19.0.5(GitLab公式リリースノート)
• GitLab Patch Release: 19.2.1, 19.1.3, 19.0.5(GitLab公式フォーラム)
• Metadata API(GitLab公式ドキュメント)
• GitLab Fixes 13 Security Flaws That Can Leak Data, Alter Pipelines, and Crash Servers(cybersecuritynews.com)
• TanStack npmサプライチェーン攻撃事件(2026年5月)の全容
• Next.js 2026年7月セキュリティリリース
• セルフホストGitサーバーの比較
• レート制限の仕組み - トークンバケット・スライディングウィンドウと429の正しい返し方
• OAuth 2.0 / OpenID Connect入門