GitLab脆弱性まとめ、自社サーバー版は19.1.2以降へ更新を

プログラムの開発現場で広く使われているGitLab（ギットラボ）を自社のサーバーに設置して使っている場合（自己ホスト型）、バージョンが19.1.2／19.0.4／18.11.7より古いままだと、他人のアカウントを乗っ取れる穴や情報が漏れる穴を含む脆弱性（情報セキュリティ上の欠陥）が未修正のまま残っています。この3系統のいずれか以降、または2026年7月16日公開の最新メジャー版19.2を使っていれば、この記事で扱う一連の脆弱性はすべて塞がっており、追加の対応は不要です。GitLab社が運営するクラウド版「GitLab.com」と専用環境「GitLab Dedicated」も修正適用済みで、利用者側の作業はありません。

GitLabは2026年6月10日・6月24日・7月8日と、ひと月足らずの間に3回のセキュリティ修正を重ね、合計34件の脆弱性を塞ぎました。中でも重いのは、グループの管理役が他メンバーのアカウントを乗っ取れる穴（CVE-2026-6552）、開発者の権限を持つ人が他人の画面で不正なプログラムを走らせられる穴（CVE-2026-10086）、そしてGitLabのAI機能から本来見えてはいけない情報が漏れる穴（CVE-2026-12053）です。GitLabは「影響を受けるバージョンを使っているすべての環境を、できるだけ早く最新版へ更新することを強く推奨する」と公式リリースで繰り返し呼びかけています。

この記事では、どのバージョンなら安全なのか、それぞれの修正で何が直ったのか、自社設置型の環境がいま何を確認すべきかを整理します。分かれ目は「自分の会社のサーバーでGitLabを動かしているかどうか」と「その番号がどこまで上がっているか」の2点です。

どんなソフトが、誰に関係するのか

GitLabは、エンジニアが書いたプログラムを保管し、複数人で共同編集し、テストや本番公開までを自動で流すための「開発の土台」です。GitHubと並ぶ代表的なサービスで、社外にコードを置きたくない企業や官公庁は、GitLabを自社のサーバーに設置して使う例が目立ちます。設計図そのものであるソースコード、本番サーバーへの鍵、外部サービスのパスワードなどが、この一箇所に集まっているのが普通です。

一連の修正が対象とするのも、その「自社設置型」の環境です。クラウド版のGitLab.comは対応が済んでおり、影響するのは自前で構築・更新しているケースに限られます。多くの企業では情報システム部門やインフラ担当が更新を管理しているため、まずは「うちのGitLabは誰が更新しているのか」を確認するところが出発点になります。

最も新しい修正：19.1.2／19.0.4／18.11.7で直った8件（2026年7月8日）

2026年7月23日時点で最も新しいセキュリティ修正は、2026年7月8日公開の19.1.2／19.0.4／18.11.7です。ここで8件の脆弱性が追加で塞がれました。6月の2回分（14件と12件）を適用済みでも、この8件は含まれていないため、6月末に更新したばかりの環境も対象になります。

CVE-2026-6896: 脆弱性一覧の画面を踏ませて不正な処理を走らせる穴

8件で最も重い1件です。有償のEEに含まれるセキュリティ機能のうち、見つかった脆弱性の証拠（エビデンス）を一覧表示するテーブルに、入力された文字のチェック漏れがありました。これは「クロスサイトスクリプティング」（XSS）と呼ばれる、表示画面に不正なプログラムを仕込む手口で、細工した内容を別の利用者が画面で開くと、その人のブラウザ上で攻撃者の処理が動きます。危険度の共通スコアCVSSは8.7で、6月に直った分析画面の穴（CVE-2026-10086）と並ぶ高さです。対象はEEの13.11以降と、影響範囲がとても広いのが特徴です。

CVE-2026-13320: Wikiのページに不正な表示を差し込める穴

プロジェクトの説明文書を置くWiki機能に、HTML（画面の表示を組み立てる記述）を不正に差し込める穴がありました。CVSSは7.3で、無償のCEと有償のEEの両方が対象です。残りの6件は中〜低の深刻度で、内訳は公式リリースで確認できます。

19.1.1／19.0.3／18.11.6で直った14件（2026年6月24日）

その2週間前、2026年6月24日の修正では14件が塞がれました。深刻度の指標である「CVSS」（脆弱性の危険度を0〜10で表す国際的な共通スコア）が高い主なものを並べます。数字が大きいほど危険度が高い、という見方で問題ありません。CE（無償のCommunity Edition）とEE（有償のEnterprise Edition）のどちらに関係するかも合わせて示します。

上記のほか、権限まわりや認可（誰が何を操作できるかの判定）の細かな不備を含め、合計14件が一度に修正されています。公開から1ヶ月がたった2026年7月23日時点でも、この記事で扱う脆弱性が実際の攻撃に使われたという報告（悪用事例）は確認されておらず、米政府CISAが公開する実際に攻撃されている脆弱性の一覧（KEV）にも載っていません。多くはGitLabの報奨金制度（バグバウンティ）を通じて研究者から報告されたものです。とはいえ、修正版が出た時点で穴の場所はおおむね公になるため、攻撃側の解析が進む前に更新を済ませるのが定石です。

6月24日分で特に重い3件をくわしく見る

CVE-2026-10086: 分析画面を踏ませて不正な処理を走らせる穴

この14件でもっとも危険度が高い1件です。GitLabの分析ダッシュボード（プロジェクトの状況をグラフで見る画面）に、入力された文字のチェック漏れがありました。これも表示画面に不正なプログラムを仕込むXSSの典型的な手口です。開発者（Developer）の権限を持つ人が悪意ある仕掛けを埋め込み、それを別の利用者が画面で開くと、その人のブラウザ上で攻撃者の用意した処理が動いてしまいます。仕込んだ内容によっては、ログイン状態の乗っ取りや、結果的なアカウント奪取につながります。CVSSは8.7、対象はEEの16.4から19.1.0まで（途中の修正版を除く）。報告者は研究者のyvvdwf氏です。

その前の6月10日のパッチでも、同じ分析画面のよく似た穴（CVE-2026-10087）が直されたばかりでした。番号が1つ違うだけの連番で、画面の別の入口に同種のチェック漏れが残っていたことになります。開発者権限は社内では比較的多くの人が持っている権限なので、配布範囲が広いぶん内部からの仕掛けに注意が要ります。

CVE-2026-10712: コード編集画面のファイル処理を悪用する穴

2件目も画面に不正なプログラムを仕込むXSSですが、舞台はブラウザ上でコードを編集する「Web IDE」という機能です。この編集画面が扱うファイル（アセット）の処理に不備があり、細工した内容を相手に開かせると、その人の画面で攻撃者の処理が動いてしまいます。CVSSは8.0で、無償のCEと有償のEEの両方が対象、影響範囲は18.10から19.1.0までです。報告者は研究者のjoaxcar氏です。

この穴はログイン自体は不要とされていますが、悪用には「標的が用意された場所を開く」という操作が前提になります。一方的に押し入る種類ではないものの、共同開発の場では他人が用意したブランチやファイルを開く機会が日常的にあるため、油断はできません。無償版を社内に立てているチームも該当します。

CVE-2026-12053: AI機能から情報が漏れる穴

3件目は、GitLabのAIアシスタント機能「Duo Workflows」に関わる情報漏えいです。AIの出力に対する絞り込みが不十分だったため、特定の条件下で、本来その利用者には見えてはいけない機密情報が引き出せる恐れがあります。対象は有償のEEで、影響するのは19.1.0です。報告者はGitLabのチームメンバー（3nvz氏、Dennis Appelt氏）です。AI支援機能が開発の現場へ入り込むほど、こうした「出力をどこまで見せてよいか」の作り込みが新しい弱点になりやすいことを示す一例です。

なお、この1件は危険度の評価が情報源によって割れています。詳しくは次の「確認しておきたい点」で触れます。

この穴を誰が、何のために狙うのか

GitLabの脆弱性と聞くと、まず思い浮かぶのは外から押し入る正体不明のハッカーかもしれません。ところがこの一連の重い穴の多くは、すでにあなたの会社のGitLabにアカウントを持っている人間、それも開発者や管理役といった一定の権限を与えられた内側の人物が起点になります。だからこそ、外向きの壁をいくら高くしても防ぎきれない種類の穴だという点を、最初に押さえておく必要があります。

狙う側として現実にあり得るのは、退職を控えて待遇に不満を抱えたエンジニア、契約が切れる間際の業務委託の開発者、共同プロジェクトに招かれた取引先の担当者、あるいはフィッシングで一人分のログイン情報を盗んで紛れ込んだ第三者です。彼らが欲しがるのは、製品の設計図そのものであるソースコード、本番サーバーへ入るための鍵、外部サービスやクラウドのパスワード、顧客リストや未公開の新機能の中身です。分析画面やコード編集画面に不正な仕掛けを一つ仕込み、それを別の利用者に開かせるだけで、その人のログイン状態を奪い、本人の権限で見られるものすべてを引き出せます。

怖いのは、GitLabが単なる保管庫ではなく、コードを自動でテストし本番へ配る「パイプライン」を握っている点です。乗っ取った先で本番デプロイ用の鍵を取り出せば、攻撃は一社にとどまりません。そのコードを取り込んでいる別の製品やサービス、つまり取引先や利用者の側まで、汚染されたプログラムが連鎖的に流れ込む経路（サプライチェーン攻撃）が開きます。実際、開発基盤を足がかりにした侵入は、内部に静かに潜んで偵察を重ね、本命の標的へ横移動していくのが典型的な流れです。

CVSSの数字は、あくまで技術的な深刻度の目盛りにすぎません。開発チームにとって本当に失われるのは、何年もかけて積み上げた製品のソースコードと、それを守ってきた信頼です。設計図と鍵を同時に持っていかれれば、復旧は「パスワードを変える」では済まず、何を見られ何を書き換えられたのかを一行ずつ確かめる作業に変わります。権限を持つ内側の一人から始まる攻撃だからこそ、更新の遅れがそのまま被害の入口になります。

19.0.2／18.11.5／18.10.8で直った12件（2026年6月10日）

さらにさかのぼると、GitLabは2026年6月10日にも12件の脆弱性をまとめて修正しています。すでに19.1.2などの修正版へ更新済みであればどの回の分も塞がっていますが、しばらく更新していなかった環境では、こちらも合わせて該当する可能性があります。この回のパッチ（修正版は19.0.2／18.11.5／18.10.8）で最も重かったのは、次の3件でした。

CVE-2026-6552: 他メンバーのアカウントを乗っ取れる穴

この回でもっとも注意すべき1件でした。GitLabには、会社が使う共通のログインの仕組み（SAML、シングルサインオン）と各メンバーのアカウントを結びつける機能があります。この紐づけ管理の権限チェックに不備があり、グループの管理役（Owner）の立場を持つ人が、同じグループの別メンバーのアカウントを乗っ取れてしまいます。乗っ取りにあたって相手のパスワードは必要ありません。CVSSは8.7で、影響するのはEEの15.5から19.0.1までです。報告したのはセキュリティ研究者のcyberjoker氏です。本人になりすませれば、その人だけがアクセスできる別グループのコードや、本人名義でのコミット（改ざんの偽装）まで可能になります。

CVE-2026-10087: 分析画面を踏ませて不正な処理を走らせる穴

GitLabの分析ダッシュボードに、入力された文字のチェック漏れ（XSS）がありました。開発者権限を持つ人が悪意ある仕掛けを埋め込み、それを別の利用者が開くと、その人のブラウザ上で攻撃者の処理が動きます。CVSSは8.7、対象はEEの17.1から19.0.1まで。報告者はyvvdwf氏です。6月24日に直ったCVE-2026-10086と同じ分析画面の連番の穴で、同種の入口が複数あったことを示しています。

CVE-2026-7250: ログインなしでサービスを止められる穴

こちらはデータを盗む類ではなく、サービスそのものを止めるタイプ（サービス妨害、DoS）です。GitLabのAPI（外部のプログラムとやり取りする窓口）が受け取るデータの処理に不備があり、細工したデータを送りつけるだけでGitLabを過負荷で停止させられます。ログインしていない相手でも実行でき、無償のCEも対象です。CVSSは7.5で、影響範囲は12.10から19.0.1までと非常に広く、報告者はsvalkanov氏です。

自分のGitLabは更新が必要か（バージョン別早見表）

いま使っているバージョンは、GitLabの管理画面、または/helpページやgitlab-rake gitlab:env:infoコマンドで確認できます。下の表で、自分の番号がどこに当てはまるかを照合してください。2026年7月23日時点の修正版は19.1.2／19.0.4／18.11.7の3系統で、ここまで上げれば6月10日・6月24日・7月8日の3回分の修正がまとめて適用されます。2026年7月16日には新しいメジャー版19.2も出ており、機能ごと新しくするなら19.2を選ぶ手もあります（19.2はこの記事の修正をすべて含みます）。

更新そのものは公式のアップグレード手順に沿って進めます。大きく飛び級する更新は途中のバージョンを経由する必要がある場合があるため、現在の番号が古いほど、計画的な段取りが要ります。すぐに本体を上げられない事情がある場合でも、外部に公開しているGitLabであれば、アクセス元の制限や監視の強化といった当座の防御を併用するのが現実的です。

技術的に見ると、なぜ自社設置型が狙われやすいのか

クラウド版のGitLab.comは、GitLab社の手で自動的に最新版へ保たれます。一方、自社サーバーに設置した環境は、更新の責任が利用企業側にあります。ここに時間差が生まれ、「修正版は出ているのに、現場のGitLabは古いまま」という状態がしばしば残ります。2026年6月から7月のように短い間隔で修正が続くと、更新作業が追いつかず、未対応のまま積み上がるリスクはなおさら高まります。攻撃側が修正内容を解析して穴の場所を特定しても、未更新の環境が世界中に残っているのが現実です。

開発基盤はソースコードと本番への鍵が一箇所に集まる「金庫」であり、近年は侵入の入口として繰り返し標的にされてきました。GitやCI/CD（テストと公開の自動化）の仕組みを足がかりに、依存先のソフトへ毒を回す手口は、パッケージのインストール時に勝手にプログラムが走る問題とも地続きです。開発まわりの部品がどこから来て何を実行するのかを継続的に点検する発想は、外部から取り込むソフトの安全性を見張る取り組みと同じ問題意識の上にあります。

この一連の穴の多くが「ログイン済みの内部利用者」を起点とする点も見逃せません。境界の壁（ファイアウォール）だけに頼る守りでは、正規のアカウントを持つ相手や、乗っ取られた一アカウントには無力です。誰がどの権限を持っているか、開発者や管理役の人数が多すぎないかといった内部の見直しが、こうした穴への現実的な備えになります。

いま取るべき対応

自社サーバーでGitLabを動かしているなら、まずバージョンを確認し、19.1.2／19.0.4／18.11.7より古ければ、そのいずれか（または最新の19.2）へ更新します。これが唯一の根本対策で、ここまで上げれば2026年6月から7月にかけての3回分・計34件の修正がまとめて入ります。GitLab.comやGitLab Dedicatedの利用者は、すでに修正が適用されているため作業は不要です。

本体の更新まで時間がかかる場合は、外部公開しているGitLabのアクセス元を社内ネットワークやVPNに絞る、開発者や管理役（Owner）の人数を必要最小限に見直す、不審なログインや設定変更の監視を強める、といった当座の手当てを並行します。2026年7月23日時点で実際の攻撃は確認されていませんが、修正の公開後は穴の場所が把握されやすくなるため、更新の先送りはそのまま危険の蓄積になります。GitLabのセキュリティ修正は今後も繰り返し出るため、公式のパッチ告知を購読し、月に一度は更新日を決めておく運用にすると、次の修正にも慌てずに済みます。

参照元

• ▸ GitLab公式 - Patch Release: 19.1.2, 19.0.4, 18.11.7（2026年7月8日）
• ▸ GitLab公式 - Patch Release: 19.1.1, 19.0.3, 18.11.6（2026年6月24日）
• ▸ GitLab公式 - Patch Release: 19.0.2, 18.11.5, 18.10.8（2026年6月10日）
• ▸ GitLab公式 - GitLab 19.2 released（2026年7月16日）
• ▸ NVD - CVE-2026-10086（分析ダッシュボードのXSS）
• ▸ NVD - CVE-2026-10712（Web IDEのXSS）
• ▸ NVD - CVE-2026-12053（Duo Workflowsの情報漏えい）
• ▸ NVD - CVE-2026-6552（Group SAML アカウント乗っ取り）
• ▸ GitLab公式サイト