開発基盤「GitLab」に緊急パッチ、ログイン不要で公開プロジェクトを消せる脆弱性はなぜ数日で悪用されたのか。CVSS9.4の中身を確かめる

まず初めに

「ログインすら要らない」というのは、家の鍵をかけ忘れているどころか、そもそも鍵穴自体が存在しなかったに等しい。しかもGitLabといえば、世界中の開発者が日々コードを積み上げている、いわば「デジタル世界の作業場」そのものだ。その作業場の入り口に、誰でも素通りできる抜け道が空いていたというのだから、これはなかなかの事態である。*攻撃者が「公開されて数分で再現できた」と報告しているあたり、防御側よりも攻撃側の方がよほど仕事が早いというのは、セキュリティの世界ではもはやお約束の展開だ。*とはいえ、GitLab社が通常の月2回のパッチ日程を待たずに緊急対応した点、そしてクラウド版はあらかじめ手当て済みだった点は、対応としては及第点をつけてよいだろう。※個人の感想です

何が起きているのか

「GitLab」は、プログラムのソースコードを管理・共有し、複数の開発者が共同で開発作業を進めるためのプラットフォームぷらっとふぉーむ(基盤となるサービス)です。企業が自社サーバーに構築して運用する「セルフマネージド」版と、GitLab社自身が運用するクラウド版「GitLab.com」の両方が提供されており、世界中の多くの企業・開発者チームが利用しています。

GitLab社は2026年8月17日、通常の隔週パッチとは別枠で、緊急のセキュリティ修正版(18.11.11、19.0.8、19.1.6、19.2.4)を公開しました。中心となる脆弱性CVE-2026-19478は、GitLabが備えるGraphQL(データの問い合わせ・操作を行うための仕組み)の処理部分に存在していました。海外のセキュリティ企業の分析によると、GraphQLの問い合わせに含まれる「フィールド名」(取得したいデータ項目を指定する部分)の処理に不備があり、攻撃者が指定した任意の文字列が、データベースを操作する内部関数の呼び出しとしてそのまま実行されてしまう仕組みだったとされています。この処理は認証を必要とせず、ネットワーク経由でGraphQLの問い合わせを1件送るだけで成立するため、攻撃の難易度は低いと評価されています。

影響を受けるのは、自社サーバーなどにGitLabを構築して運用している「セルフマネージド」環境で、バージョン18.2以降19.2.4未満の各系列が対象です。攻撃が成立すると、公開プロジェクト(誰でも閲覧できる設定のプロジェクト)の情報を第三者が書き換えたり削除したりできるおそれがあります。一方、GitLab社自身が運営するクラウド版のGitLab.comと、専用インスタンスを提供する「GitLab Dedicated」については、修正版の公開前から社内で対応済みだったため、これらのサービスの利用者が追加の対応を取る必要はないとGitLab社は説明しています。セキュリティ企業からは、修正版の公開から日を置かずに、実際の攻撃とみられる通信が観測されたとの報告も出ています。技術的な検証コード(PoCぴーおーしー、Proof of Concept)についても、修正版の公開後に一般公開されています。

なぜ重要なのか

GitLabは、企業の業務システムから個人開発者のプロジェクトまで、世界中の非常に幅広い開発現場で使われている基盤ソフトウェアです。今回の脆弱性のように、認証を必要とせず、しかも利用者の操作(クリックなど)も介さずに成立してしまう「ゼロクリック」型の欠陥は、攻撃者にとって悪用のハードルが極めて低く、セキュリティ上のリスクが大きいとされています。

また、修正版の公開からごく短期間で実際の攻撃が観測されたという点も重要です。近年、ソフトウェアの脆弱性が公表されると、攻撃者側が検証コードを解析し、実際の攻撃に転用するまでの期間が年々短くなる傾向が指摘されており、今回の事例もその一つとして受け止められています。セルフマネージド環境を運用する組織にとっては、修正版の公開後、可能な限り早く更新を適用することの重要性を改めて示す事例です。

私たちへの影響

一般の利用者がGitLabを直接操作する機会は多くありませんが、企業のシステム開発の裏側で広く使われている基盤であるため、対応が遅れた組織のシステムを通じて、間接的な影響が生じる可能性はあります。ただし、今回の脆弱性で書き換え・削除の対象となるのは「公開プロジェクトの情報」であり、報道されている範囲では、利用者の個人情報やクレジットカード情報などが直接盗まれるといった内容は確認されていません。

自社でGitLabのセルフマネージド環境を運用している企業の管理者にとっては、対象バージョン(18.2以降19.2.4未満)を使用していないかを確認し、該当する場合は修正版へ速やかに更新することが求められます。修正版への更新がすぐに行えない場合の暫定的な対策として、GraphQLのAPIエンドポイント(/api/graphql)へのネットワークアクセスを制限する方法も報告されています。

初心者が知っておくべきこと

「GraphQL」とは、Webサービスがデータをやり取りする際に使われる仕組みの一種で、利用者(この場合はプログラム)が必要なデータの種類を細かく指定して問い合わせできるのが特徴です。従来型の仕組みに比べて柔軟な問い合わせができる一方、今回のように問い合わせ内容の扱いに不備があると、想定していない処理が実行されてしまうリスクもあります。

「コードインジェクション」とは、本来はデータとして扱われるべき入力値の中に、攻撃者が仕込んだ命令(コード)を紛れ込ませ、システム側にそれを実行させてしまう攻撃手法の総称です。今回のケースでは、GraphQLの問い合わせに含まれる項目名の指定が、データベースを操作する内部の命令としてそのまま実行されてしまう点が問題でした。

IT Postの見方

IT Postでは、今回の一件が示しているのは、便利な機能ほど攻撃の糸口にもなり得るという、開発現場にとって耳の痛い教訓だと考えます。GraphQLは、開発者にとって柔軟で使い勝手の良い仕組みですが、その柔軟さの裏側で、想定外の入力をどこまで厳密にチェックできているかが常に問われることを、今回の事例は改めて突きつけたとIT Postでは考えます。

一方で、GitLab社が通常のリリーススケジュールを崩してでも緊急パッチを出し、なおかつ自社が運営するクラウド版をあらかじめ手当てしていた対応スピードは、評価に値するとIT Postでは考えます。オープンソースを含む基盤ソフトウェアの脆弱性は今後も避けられない以上、重要なのは「見つからないこと」よりも「見つかった後にどれだけ早く動けるか」であり、その点で今回のGitLab社の対応は一つの模範例になり得るとIT Postでは考えます。※個人の感想です

今後どうなりそうか

セキュリティ企業各社は、同種のGraphQL関連の脆弱性について引き続き調査を進めるとみられます。GitLab社は今後も定期的なセキュリティ更新を続ける方針で、セルフマネージド環境を運用する組織には、修正版への迅速な移行と、GraphQLエンドポイントへのアクセス制限などの多層的な対策が引き続き求められます。IT Postでは、この脆弱性を悪用した具体的な被害事例が確認された場合には、あらためて取り上げます。