GitLabにアカウント乗っ取りの脆弱性、社内設置は今すぐ更新 CVE-2026-6552
GitLabが12件の脆弱性をまとめて修正しました。グループの管理役の権限で他の利用者のアカウントを乗っ取れる穴や、ログインなしでサービスを止められる穴を含みます。自社サーバーに置いて使っている企業は、最新版（19.0.2／18.11.5／18.10.8）へ今すぐ更新が必要です。GitLab.com利用者は対応済みです。
堀川 慎
Backend Engineer / AWS / Django / Go
GitLabが12件の脆弱性をまとめて修正しました。グループの管理役の権限で他の利用者のアカウントを乗っ取れる穴や、ログインなしでサービスを止められる穴を含みます。自社サーバーに置いて使っている企業は、最新版（19.0.2／18.11.5／18.10.8）へ今すぐ更新が必要です。GitLab.com利用者は対応済みです。
プログラムの開発現場で広く使われているGitLab（ギットラボ）が、2026年6月10日、12件の脆弱性をまとめて修正する緊急アップデートを公開しました。GitLabは、会社のソースコードを保管し、テストや公開までを自動で回すための開発基盤で、国内でも自社サーバーに設置して使う企業が数多くあります。
今回の修正で最も重いのは、他人のアカウントをまるごと乗っ取れる穴（CVE-2026-6552）と、ログインしていない相手でもサービスを止められる穴（CVE-2026-7250）の2つです。GitLabは「影響を受けるバージョンを使っているすべての環境を、できるだけ早く最新版へ更新することを強く推奨する」と公式リリースで呼びかけています。
対象になるのは、自社サーバーにGitLabを置いて運用している環境（自己ホスト型）です。GitLab社が運営するクラウド版「GitLab.com」と専用環境「GitLab Dedicated」は、すでに修正済みのため利用者側の作業は不要です。つまり「自分の会社のサーバーでGitLabを動かしているかどうか」が、今すぐ動くべきかどうかの分かれ目になります。
どんなソフトが、誰に関係するのか
GitLabは、エンジニアが書いたプログラムを保管し、複数人で共同編集し、テストや本番公開までを自動で流すための「開発の土台」です。GitHubと並ぶ代表的なサービスで、社外にコードを置きたくない企業や官公庁は、GitLabを自社のサーバーに設置して使う例が目立ちます。設計図そのものであるソースコード、本番サーバーへの鍵、外部サービスのパスワードなどが、この一箇所に集まっているのが普通です。
今回のアップデートが対象とするのは、その「自社設置型」の環境です。前述のとおりクラウド版のGitLab.comは対応が済んでおり、影響するのは自前で構築・更新しているケースに限られます。多くの企業では情報システム部門やインフラ担当が更新を管理しているため、まずは「うちのGitLabは誰が更新しているのか」を確認するところが出発点になります。
| 使い方 | 今回の影響 | 必要な対応 |
|---|---|---|
| 自社サーバーに設置 （自己ホスト型） | 影響あり | 今すぐ最新版へ更新 |
| GitLab.com （クラウド版） | 対応済み | 作業不要 |
| GitLab Dedicated （専用環境） | 対応済み | 作業不要 |
今回まとめて直った穴の一覧
12件のうち、深刻度の指標である「CVSS」（脆弱性の危険度を0〜10で表す国際的な共通スコア）が高い主なものを並べます。数字が大きいほど危険度が高い、という見方で問題ありません。
| 番号 | 内容 | 起きること | 必要な立場 | 対象 | 危険度 |
|---|---|---|---|---|---|
| CVE-2026-6552 | 外部ログイン連携 の権限不備 | 他メンバーの アカウント乗っ取り | グループ管理役 | EE | 8.7 |
| CVE-2026-10087 | 分析画面の 入力チェック漏れ | 標的の画面で 不正な処理を実行 | 開発者＋相手の操作 | EE | 8.7 |
| CVE-2026-7250 | APIのデータ 解析の不備 | ログインなしで サービス停止 | 不要（認証なし） | CE・EE | 7.5 |
| CVE-2026-8589 | グループ設定の 文字列処理不備 | 不正なメール アドレスの追加 | グループ管理役 | EE | 7.3 |
| CVE-2026-9204 | 取り込み機能の 送信先制御不備 | 社内ネットワーク への不正アクセス | 開発者 | CE・EE | 5.3 |
上記のほか、サービスを重くする不具合や権限まわりの細かな不備を含め、合計12件が一度に修正されています。今のところ、これらが実際の攻撃に使われたという報告（悪用事例）は確認されておらず、すべてGitLabの報奨金制度（バグバウンティ）を通じて研究者から報告されたものです。とはいえ、修正版が出た時点で穴の場所はおおむね公になるため、攻撃側の解析が進む前に更新を済ませるのが定石です。
この穴を誰が、何のために狙うのか
GitLabの脆弱性と聞くと、まず思い浮かぶのは外から押し入る正体不明のハッカーかもしれません。ところが今回いちばん重い2件は、すでにあなたの会社のGitLabにアカウントを持っている人間、しかも一定の役職を与えられた内側の人物が起点になります。だからこそ、外向きの壁をいくら高くしても防ぎきれない種類の穴だという点を、最初に押さえておく必要があります。
狙う側として現実にあり得るのは、退職を控えて待遇に不満を抱えたエンジニア、契約が切れる間際の業務委託の開発者、共同プロジェクトに招かれた取引先の担当者、あるいはフィッシングで一人分のログイン情報を盗んで紛れ込んだ第三者です。彼らが欲しがるのは、製品の設計図そのものであるソースコード、本番サーバーへ入るための鍵、外部サービスやクラウドのパスワード、顧客リストや未公開の新機能の中身です。グループの管理役という肩書きを一つ握られた瞬間、同じグループにいる別メンバーのアカウントが本人になりすまして乗っ取られ、その人の権限で見られるものすべてが相手の手に渡ります。
怖いのは、GitLabが単なる保管庫ではなく、コードを自動でテストし本番へ配る「パイプライン」を握っている点です。乗っ取った先で本番デプロイ用の鍵を取り出せば、攻撃は一社にとどまりません。そのコードを取り込んでいる別の製品やサービス、つまり取引先や利用者の側まで、汚染されたプログラムが連鎖的に流れ込む経路（サプライチェーン攻撃）が開きます。実際、開発基盤を足がかりにした侵入は、内部に静かに潜んで偵察を重ね、本命の標的へ横移動していくのが典型的な流れです。
CVSS 8.7という数字は、あくまで技術的な深刻度の目盛りにすぎません。開発チームにとって本当に失われるのは、何年もかけて積み上げた製品のソースコードと、それを守ってきた信頼です。設計図と鍵を同時に持っていかれれば、復旧は「パスワードを変える」では済まず、何を見られ何を書き換えられたのかを一行ずつ確かめる作業に変わります。権限を持つ内側の一人から始まる攻撃だからこそ、更新の遅れがそのまま被害の入口になります。
主な3件をくわしく見る
CVE-2026-6552: 他メンバーのアカウントを乗っ取れる穴
今回もっとも注意すべき1件です。GitLabには、会社が使う共通のログインの仕組み（SAML、シングルサインオン）と各メンバーのアカウントを結びつける機能があります。この紐づけ管理の権限チェックに不備があり、グループの管理役（Owner）の立場を持つ人が、同じグループの別メンバーのアカウントを乗っ取れてしまいます。乗っ取りにあたって相手のパスワードは必要ありません。CVSSは8.7で、影響するのはEE（有償のEnterprise Edition）の15.5から19.0.1までです。報告したのはセキュリティ研究者のcyberjoker氏です。
「管理役なら元々強い権限では」と思うかもしれませんが、グループの管理役と、個々のメンバー本人になりすませることはまったく別の話です。本人になりすませれば、その人だけがアクセスできる別グループのコードや、本人名義でのコミット（改ざんの偽装）まで可能になります。社内に多数のグループを抱える大きな組織ほど、影響が連鎖しやすい穴です。
CVE-2026-10087: 分析画面を踏ませて不正な処理を走らせる穴
GitLabの分析ダッシュボード（プロジェクトの状況をグラフで見る画面）に、入力された文字のチェック漏れがありました。これは「クロスサイトスクリプティング」（XSS）と呼ばれる、表示画面に不正なプログラムを仕込む典型的な手口です。開発者（Developer）の権限を持つ人が悪意ある仕掛けを埋め込み、それを別の利用者が画面で開くと、その人のブラウザ上で攻撃者の用意した処理が動いてしまいます。仕込んだ内容によっては、ログイン状態の乗っ取りや、結果的なアカウント奪取につながります。CVSSは8.7、対象はEEの17.1から19.0.1まで。報告者は研究者のyvvdwf氏です。
悪用には「標的となる相手がその画面を開く」という操作が必要なので、CVE-2026-6552ほど一方的ではありません。それでも、開発者権限は社内では比較的多くの人が持っている権限です。配布範囲が広いぶん、内部からの仕掛けには十分に注意が要ります。
CVE-2026-7250: ログインなしでサービスを止められる穴
3件目は毛色が違い、データを盗む類ではなく、サービスそのものを止めるタイプ（サービス妨害、DoS）です。GitLabのAPI（外部のプログラムとやり取りする窓口）が受け取るデータの処理に不備があり、細工したデータを送りつけるだけでGitLabを過負荷で停止させられます。重要なのは、これがログインしていない相手でも実行できる点と、有償のEEだけでなく無償のCE（Community Edition）も対象である点です。CVSSは7.5で、影響範囲は12.10から19.0.1までと非常に広く、報告者は研究者のsvalkanov氏です。無償版を社内に立てているチームも、これだけは確実に該当します。
自分のGitLabは更新が必要か（バージョン別早見表）
いま使っているバージョンは、GitLabの管理画面、または/helpページやgitlab-rake gitlab:env:infoコマンドで確認できます。下の表で、自分の番号がどこに当てはまるかを照合してください。修正版は19.0.2／18.11.5／18.10.8の3系統です。
| いま使っている版 | 状態 | 上げ先 | 優先度 |
|---|---|---|---|
| 19.0.0 〜 19.0.1 | 影響あり | 19.0.2 | 高 |
| 18.11.0 〜 18.11.4 | 影響あり | 18.11.5 | 高 |
| 17.1 〜 18.10.7 | 影響あり | 18.10.8 | 高 |
| 12.10 〜 17.0 | 停止系の穴は該当 （要個別確認） | サポート版へ 順を追って更新 | 高 |
| GitLab.com / Dedicated | 対応済み | 作業不要 | — |
更新そのものは公式のアップグレード手順に沿って進めます。大きく飛び級する更新は途中のバージョンを経由する必要がある場合があるため、現在の番号が古いほど、計画的な段取りが要ります。すぐに本体を上げられない事情がある場合でも、外部に公開しているGitLabであれば、アクセス元の制限や監視の強化といった当座の防御を併用するのが現実的です。
技術的に見ると、なぜ自社設置型が狙われやすいのか
クラウド版のGitLab.comは、GitLab社の手で自動的に最新版へ保たれます。一方、自社サーバーに設置した環境は、更新の責任が利用企業側にあります。ここに時間差が生まれ、「修正版は出ているのに、現場のGitLabは古いまま」という状態がしばしば残ります。攻撃側が修正内容を解析して穴の場所を特定しても、未更新の環境が世界中に残っているのが現実です。
開発基盤はソースコードと本番への鍵が一箇所に集まる「金庫」であり、近年は侵入の入口として繰り返し標的にされてきました。GitやCI/CD（テストと公開の自動化）の仕組みを足がかりに、依存先のソフトへ毒を回す手口は、パッケージのインストール時に勝手にプログラムが走る問題とも地続きです。開発まわりの部品がどこから来て何を実行するのかを継続的に点検する発想は、外部から取り込むソフトの安全性を見張る取り組みと同じ問題意識の上にあります。
今回の穴の多くが「ログイン済みの内部利用者」を起点とする点も見逃せません。境界の壁（ファイアウォール）だけに頼る守りでは、正規のアカウントを持つ相手や、乗っ取られた一アカウントには無力です。誰がどの権限を持っているか、管理役の人数は適切かといった内部の見直しが、こうした穴への現実的な備えになります。
いま取るべき対応
自社サーバーでGitLabを動かしているなら、まずバージョンを確認し、該当すれば19.0.2／18.11.5／18.10.8のいずれかへ更新します。これが唯一の根本対策です。GitLab.comやGitLab Dedicatedの利用者は、すでに修正が適用されているため作業は不要です。
本体の更新まで時間がかかる場合は、外部公開しているGitLabのアクセス元を社内ネットワークやVPNに絞る、管理役（Owner）の人数を必要最小限に見直す、不審なログインや設定変更の監視を強める、といった当座の手当てを並行します。今のところ実際の攻撃は確認されていませんが、修正の公開後は穴の場所が把握されやすくなるため、更新の先送りはそのまま危険の蓄積になります。