GitLab CE/EEに存在する深刻度クリティカルのセキュリティ脆弱性により、アカウントもログイン認証情報も持たないリモート攻撃者が、プラットフォームのGraphQL機能を悪用して、一般公開されているプロジェクトやユーザーデータを操作・削除できる可能性があります。
この不具合はCVE-2026-19478として識別されており、コードインジェクションの脆弱性です。GitLabが今週公表した2件の脆弱性のうちの1つとなります。GitLabは、同社のソフトウェア開発・DevOpsプラットフォームを自己管理（セルフマネージド）版で運用している組織に対し、月曜日にリリースされた新バージョンへ直ちにアップグレードするよう求めていますが、パッチを適用したからといって、プロジェクトを管理する企業などが抱えるリスクが完全になくなるわけではありません。
認証不要で悪用可能な2つの問題、セルフマネージド利用者に影響
GitLabはこの深刻な脆弱性にCVSSスコア9.4を割り当てています。悪用に認証もユーザー操作も必要とせず、データの完全性と可用性への影響が大きいためです。この不具合は、GitLab Community Edition/Enterprise Edition（CE/EE）の18.2以降19.11.11より前、19.0以降19.0.8より前、19.1以降19.1.6より前、19.2以降19.2.4より前の全バージョンに影響します。
もう一方の深刻度が低い脆弱性はCVE-2026-19650として追跡されており、GitLabのGraphQLマルチプレックスクエリハンドラーに存在するクロスサイトリクエストフォージェリ（CSRF）の問題です。未認証の攻撃者が特別に細工したGETリクエストを使って不正な変更を引き起こせる可能性があります。この不具合はCVE-2026-19478と同じバージョンのGitLab CE/EEに影響し、CVSSスコアは7.1です。
GitLabが管理するGitLab.comやGitLab Dedicatedのサービスを利用している組織は、これらの環境がすでにパッチ適用済みであるため、対応の必要はありません。しかし、セルフマネージド版を利用している組織は、GitLab CEおよびEEの新リリースバージョンである19.2.4、19.1.6、19.0.8、18.11.11へ直ちにアップデートする必要があります。
GitLabの帯域外セキュリティアップデートでは、脆弱性の技術的な詳細は公表されていません。これはパッチ公開から90日間はそうした情報を非公開にするという同社のポリシーに沿ったものですが、攻撃の検知という点では問題になり得ます。
技術的詳細の不足が緩和策の難題に
Suzu Labsでシニアディレクター・AIソリューション&サイバーセキュリティを務めるJacob Krell氏によれば、透明性の欠如によって組織が自社の環境が侵害されているかどうかを判断しにくくなっている一方で、セキュリティチームがリスクプロファイルを強化するために取れる対策もあるといいます。
「まだ公表されていない攻撃の仕組みに対して、信頼できるエクスプロイト特化型のシグネチャを書くことはできません」と同氏は述べています。その代わりに、チームはGitLabのGraphQL、API、リバースプロキシ、監査ログの保全に注力し、/api/graphqlへの異常なリクエスト、特に原因不明のプロジェクト削除、設定変更、ユーザーデータの改変に関連するものがないか確認すべきだと同氏は推奨しています。
「GitLabのGraphQLログにはクエリ文字列と変数が記録されるので、そこに異常なディレクティブやミューテーション（変更操作）の活動がないか探してください」と同氏はアドバイスし、技術的な詳細が完全に明らかになるまでは、調査よりも封じ込めに重点を置くのが賢明だと付け加えています。
Krell氏によれば、影響を受けるインターネット公開型のGitLabインスタンスを運用している組織や、外部から到達可能なGraphQLエンドポイントを持つ組織は、優先的にパッチ適用済みバージョンへアップデートすべきだといいます。GitLabが8月12日に予定していた通常のパッチリリースからわずか数日後に帯域外アップデートをリリースしたという事実は、同社が新たな脆弱性がもたらす脅威をいかに深刻に受け止めているかを示しています。
「ベンダーがこれほど迅速に帯域外対応に踏み切った場合、それはCVSSスコアに加えて深刻度を示すシグナルだと捉えるべきです」とKrell氏は述べています。一方、バージョン18.2から18.10に留まっている組織は、これらのブランチに修正が提供されていないため、アップデートの道のりがより困難になる可能性があります。GitLabが求める必須のアップグレード手順に従いながら、サポート対象の修正済みブランチへ移行する必要があると同氏は述べています。
XCapeのCOOであるNoelle Murata氏も、通常のパッチリリースからわずか1週間足らずで緊急パッチを投入するという通常のペースを崩す判断を下したGitLabの対応は危険信号だと同意しています。CVE-2026-19478が、認証情報もユーザー操作も不要で容易に悪用可能に見えることが、緊急性をさらに高めていると同氏は述べています。
「すぐにパッチを適用できないチームは、インスタンスを公開インターネットから切り離すか、VPNの背後に置くべきです。WAFやリバースプロキシによって/api/graphqlへの未認証の外部トラフィックを制限し、すべての公開リポジトリを監査してください」とMurata氏は指摘しています。管理者権限を持つ個人は、GitLabのセッションを開いている間、信頼できない送信元からのリンクをクリックする際には注意を払うべきです。
GitHubのGraphQLアーキテクチャ、防御が難しい構造
GitLabの緊急アドバイザリは、未認証の攻撃者がCVE-2026-19478を悪用する際に利用するインターフェースであるGraphQLにも注目を集めています。GraphQLは、Webアプリケーションが単一の柔軟なインターフェースを通じて、サーバーやその他のバックエンドに保存されたデータを要求・変更できるようにする技術です。例えば、Webアプリケーションは同じインターフェースを通じてサーバーにリクエストを送信することで、ユーザーのプロフィール情報を取得したり、プロジェクトの詳細を表示したり、アカウント設定を更新したりできます。
「GraphQLの設計上の強みこそが、まさに防御を難しくしているのです」とMurata氏は指摘します。「すべての処理が単一のエンドポイントを経由するため、パスベースのWAFルールでは、API全体を機能不全にすることなく危険な操作だけを切り分けることができません」
多くの異なる操作が同じインターフェースを共有し、複雑な形で組み合わせられるため、単一のセキュリティ上の欠陥が多くの機能に影響を及ぼす可能性があるとMurata氏は述べています。同時に、ベンダーが何を注視すべきか正確に明らかにしていない状況では特に、正当な活動と悪意ある活動を見分けるのが難しくなります。
「GitLabから完全な技術的詳細が得られない中、防御側は不完全な情報で対応せざるを得ず、不安な立場に置かれています」と、BreachLockのCEO兼共同創業者であるSeemant Sehgal氏は付け加えています。組織がすべきことは、GraphQL APIのログに異常がないか確認することです。特に、プロジェクトやユーザーデータのエンドポイントに触れる未認証のリクエストで、通常のトラフィックパターンと一致しないものに注目すべきだといいます。
「プロジェクト設定への予期しない変更、削除、あるいは対応する認証済みセッションが存在しないユーザー記録の変更は、調査する価値があります」とSehgal氏は述べています。「今のうちに通常時の活動をベースラインとして把握しておいてください。そうした比較こそが、異常を可視化する鍵となるからです」
