GitLab緊急パッチ、未認証で公開プロジェクト削除

GitLabは2026年8月17日、深刻度「クリティカル」の脆弱性を修正する定例外の緊急パッチ（19.2.4 / 19.1.6 / 19.0.8 / 18.11.11）を公開しました。目玉は CVE-2026-19478（CVSS 3.1 基本値 9.4）。特定の条件下で、認証なしの攻撃者が公開プロジェクトやユーザーデータを遠隔から改ざん・削除できるおそれがあります。

対応が必要なのはセルフマネージド（自社サーバに設置した）GitLabだけです。GitLab.com と GitLab Dedicated はすでに修正版で稼働しており、利用者側の作業は不要とされています。社内のどこかに自前のGitLabがあるなら、まず版数の確認から始めてください。

この記事でわかること

  • 今回の緊急パッチで直った脆弱性2件の中身（CVE番号・CVSS・攻撃の前提）
  • 自社が影響を受けるかを判定する具体的な手順
  • 「GraphQLのミューテーションは常に認証が必要」という前提が崩れることの意味
  • 資産台帳に載っていない“開発部門のGitLab”をどう見つけるか

GitLabとは何者か──「うちは開発をしていない」でも無関係とは限らない

GitLabとは、ソースコードの管理（Gitリポジトリ）、コードレビュー、CI/CDによる自動ビルド・自動デプロイまでを1つにまとめたDevOpsプラットフォームです。

  • 誰が使うか：主に開発部門や情報システム部門の内製チーム。社内システムの改修履歴、運用スクリプト、インフラ構成（IaC）の置き場としても使われます。
  • どんな形で存在するか：SaaS版（GitLab.com）と、自社サーバに設置するセルフマネージド版の2形態があります。今回影響を受けるのは後者です。
  • 1台に何が入っているか：Linuxパッケージ（Omnibus）版は、NGINX・Puma・PostgreSQL・Redis・Sidekiq・Gitaly などをまとめて1台に同梱してインストールします（公式アーキテクチャ資料）。「GitLabを1台入れた」時点で、Webサーバとデータベースを含む一式が社内に立っている状態になります。

情シスにとっての厄介さはここです。GitLabはミドルウェアではなく“サーバ丸ごと”として、開発部門の判断で立てられることが多い。資産管理台帳に「GitLab」という行がなくても、部門サーバや検証用VM、クラウド上のインスタンスとして動いている可能性があります。「うちはGitLabを契約していない」は、社内に存在しないことの証明にはなりません。

何が起きたのか

GitLabは通常、月2回（第2・第4水曜）の定例でセキュリティリリースを出しています。今回はそのサイクルを外したクリティカル・パッチリリースで、修正された脆弱性は2件です。

CVE 深刻度 CVSS 3.1 概要
CVE-2026-19478 クリティカル 9.4
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H		 GraphQLディレクティブを介したコードインジェクション。特定条件下で、未認証の利用者が公開プロジェクトやユーザーデータを遠隔から改ざん・削除できる
CVE-2026-19650 高 7.1
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L		 GraphQLの多重（multiplex）クエリ処理における検証不備によるCSRF。GETリクエスト経由でミューテーション（更新系操作）が実行され得る

いずれもHackerOneのバグ報奨金プログラム経由での報告です（CVE-2026-19478 は hiimguardian 氏、CVE-2026-19650 は kreep 氏）。GitLabのアドバイザリには実際の悪用（in the wild）に関する記述はなく、2026年8月18日時点で公開されたエクスプロイトコードも確認されていません。技術的な詳細は、GitLabの慣例どおりパッチ公開から90日後（2026年11月頃）に開示される見込みです。

なぜ「未認証でデータが消せる」ことが起きるのか

ポイントはGraphQLです。GraphQLはAPIの問い合わせ言語で、GitLabは /api/graphql にエンドポイントを公開しています。GitLabの公式ドキュメントは認証について明確にこう定めています——一部の参照系クエリは認証なしでも実行できるが、ミューテーション（データを書き換える操作）は常に認証を必要とする（GraphQL API 公式ドキュメント）。

今回の2件は、いずれもその設計上の前提が回避されてしまう類の欠陥だと読めます。CVE-2026-19478 のCVSSベクターを見ると、PR:N（権限不要）UI:N（利用者の操作不要）AV:N（ネットワーク経由）が揃い、影響は I:H（完全性=高）A:H（可用性=高）。「読まれる」より「壊される・消される」方向に振れた脆弱性です。機密性が C:L（低）にとどまるため、情報漏えい事案としてよりもデータ破壊・改ざん事案として身構えるほうが実態に近いでしょう。

なお、CVSSの数値そのものは「自社にとっての緊急度」ではありません。深刻度評価が組織によって割れる理由も併せて押さえておくと、社内説明がしやすくなります。

影響を受けるバージョンと修正版

系列 影響を受ける範囲 修正版
18.2 以降 18.11.11 未満 18.11.11
19.0 系 19.0.8 未満 19.0.8
19.1 系 19.1.6 未満 19.1.6
19.2 系 19.2.4 未満 19.2.4

Community Edition（CE）・Enterprise Edition（EE）の両方が対象です。無償のCEだから関係ない、ということはありません。GitLabは「すべてのインストールを可能な限り速やかに最新版へアップグレードすること」を強く推奨しています。

影響範囲が 18.2 まで遡る点にも注意が必要です。「しばらく上げていない古いGitLab」ほど当たっている可能性が高く、かつ古い版はバージョン飛び越えのアップグレード経路（アップグレードパス）を確認する必要があるため、作業時間の見積もりも変わります。

自社が該当するか、どう確認するか

「社内にGitLabがあるかどうか分からない」段階から始められる順序で整理します。

  1. 版数を確認する：ブラウザで https://<GitLabのホスト>/help を開くと、ページ上部にバージョンが表示されます。サーバに入れるなら、Linuxパッケージ版は sudo gitlab-rake gitlab:env:info でも確認できます（公式：GitLabのバージョンを調べる）。
  2. 存在そのものを洗い出す：社内ネットワークのスキャンで /api/graphql や /users/sign_in が応答するホストを探す、内部DNSを git / gitlab / scm といった名前で検索する、クラウド側のインスタンス一覧をタグ横断で確認する——といった地道な方法が確実です。
  3. インターネットからの到達性を確認する：今回の脆弱性は未認証・利用者操作不要で成立し得ます。外部公開されているGitLabが最優先です。社外から到達できるか（VPN内限定か、IP制限があるか）を切り分け、公開されているものから順に手を付けてください。
  4. 公開プロジェクトの棚卸し：脆弱性の記述は「公開プロジェクトおよびユーザーデータ」を対象としています。意図せず可視性が Public のままになっているプロジェクトがないか、この機会に確認する価値があります。

現場目線の課題

正直なところ、この手のニュースで一番しんどいのは「自社にそれがあるかどうかを情シスが把握しきれていない」ことだと思います。GitLabはまさにその典型で、開発部門が自分たちの生産性のために立てたサーバは、悪意なく台帳から抜け落ちます。責める話ではなく、構造的にそうなりやすいのです。

加えて、GitLabのアップグレードは「パッチを当てる」より「システムを更新する」に近い作業です。データベースのマイグレーションが走り、CI/CDが止まれば開発チームの手も止まります。だから緊急パッチが出ても、開発部門との調整なしに当日中に上げるのは難しい。「今すぐ上げてください」と言うだけでは現場は動きません。「外部公開されているか」「公開プロジェクトがあるか」で優先度を絞り、止められる時間帯を一緒に決めるところまで踏み込むのが現実的です。

そしてもう一つ。GitLabは8月12日の定例で13件、6月にも13件と、短い周期で脆弱性が公表され続けています。修正が速いこと自体は健全さの証でもありますが、受け手側は「毎回その都度対応する」運用では確実に息切れします。定例日をあらかじめカレンダーに入れておき、今回のような緊急パッチだけを例外扱いにする運用へ切り替えないと回りません。同じ構図はGiteaなど他のセルフホスト型Git基盤にも当てはまります。

情シスはどうすべきか

個別の対処は上記のとおりですが、根っこにあるのは「把握できていない資産をどう減らすか」という運用の問題です。自前でチェックリストを作り込むより、公的機関の指針を土台にしたほうが早く、社内説明にも使えます。

あわせて、開発部門への働きかけも忘れずに。「勝手に立てるな」ではなく「立てるのは構わない。ただし立てたら教えてほしい、外部公開だけは相談してほしい」という伝え方のほうが、結果的に把握できる資産は増えます。地道な啓発ですが、台帳の精度はこうした関係づくりでしか上がりません。

中長期の視点

ソースコード管理基盤は、いまや「情報が集まる場所」であると同時に「本番環境への経路」でもあります。CI/CDが繋がっていれば、リポジトリの改ざんはそのまま本番へのデプロイに化けかねません。今回の脆弱性は完全性（I:H）への影響が高く評価されていますが、その先には改ざんされたコードが自動で本番へ流れるというサプライチェーン的なリスクが控えています。

したがって、GitLabのような基盤は「開発の道具」ではなく本番システムに準じる重要資産として扱うのが妥当です。具体的には、外部公開の是非を定期的に見直す、管理者アカウントに多要素認証を必須化する、バックアップからの復旧を実際に試しておく——といった基本の徹底が効きます。緊急パッチのたびに慌てる状態から抜け出せるかどうかは、平時にどこまで前提を固めておけるかにかかっています。

まとめ

  1. 2026年8月17日、GitLabが定例外の緊急パッチを公開。CVE-2026-19478（CVSS 9.4）は、認証なしで公開プロジェクトやユーザーデータを改ざん・削除できるおそれがある。修正版は 19.2.4 / 19.1.6 / 19.0.8 / 18.11.11。
  2. 対応が必要なのはセルフマネージド環境のみ。GitLab.com・GitLab Dedicated は対応済み。影響範囲は 18.2 まで遡るため、更新が滞っている環境ほど該当しやすい。
  3. 優先順位は「外部公開されているか」で決める。まず /help や gitlab-rake gitlab:env:info で版数を確認し、台帳にない“開発部門のGitLab”を洗い出すところから着手する。

出典

タイトルとURLをコピーしました