GitLab脆弱性の対応｜深刻度10.0・悪用確認済みの更新手順

公開日2026年10月31日
約11分で読めます

目次8

2026年10月29日、米国のセキュリティ機関CISAは、GitLab（ギットラボ）の脆弱性 CVE-2026-97229 を「実際に悪用が確認された脆弱性」の一覧に加えました。深刻度は最高の10.0。修正版は10月12日に出ていますが、まだ更新していないサーバーが狙われています。

この記事では、自社でGitLabを動かしている会社だけでなく、ソースコードを開発会社のGitLabに預けている会社も含めて、確かめることと対応の手順を順番に説明します。

この記事のポイント

自社のサーバーでGitLabを動かしている → 今すぐ、使っている系統の最新版（2026年10月29日時点で19.5.3／19.4.5／19.3.7／19.2.10 など）に更新しましょう。
GitLab.com（クラウド版）だけを使っている → GitLab側で修正済みです。対応は不要です。
原因は、GitLabが使っているプログラミング言語「Ruby」の中にありました。公式パッケージ以外の方法で入れたGitLabは、Rubyの更新も必要です。
10月21日には、同じく深刻度10.0の別の脆弱性（CVE-2026-110264）も直っています。最新版に上げれば両方まとめて直ります。

10.0

深刻度（CVSS・最高値）

悪用確認

CISAが10月29日に認定

約2.6万台

更新前の版で動いていたサーバー（10月13日時点・世界）

ことばの説明

GitLab＝プログラム（ソースコード）を保管し、チームで共有したり、自動でテスト・公開したりするための仕組みです。自社のサーバーに入れて使う方法（セルフマネージド）と、クラウドで使う方法（GitLab.com）があります。

CI/CD（シーアイ・シーディー）＝プログラムのテストや本番への公開を自動で行う仕組みのことです。

脆弱性（ぜいじゃくせい）＝システムの"弱いところ"。悪い人に見つかると、そこから攻撃されるおそれがあります。

どんな脆弱性？なぜ危ないの？

GitLabの公式発表によると、CI/CDの設定ファイルの中に、細工した「正規表現（文字の並びを探すための書き方）」を入れると、ログインしていない攻撃者でも、GitLabのサーバー上で好きなプログラムを動かせるおそれがあります。

GitLabのサーバーには、ふつう次のようなものが入っています。サーバーを乗っ取られると、これらがまとめて盗まれたり、書き換えられたりするおそれがあります。

ソースコード

自社サービスや業務システムのプログラム本体です。

本番環境のパスワードや鍵

自動公開のために、サーバーやクラウドのログイン情報が保存されていることがよくあります。

社員や取引先のアカウント

メールアドレスや、ほかのサービスと同じパスワードを使っている人の情報です。

本当に「ログインなし」で攻撃できる？

GitLabとCISAは「認証不要（ログインなし）」としています。一方、米Rapid7社の検証では、先に「公開されたプロジェクトに書き込める状態」が必要でした。ただし、だれでもユーザー登録できる設定のGitLabでは、この条件はかんたんに満たされてしまいます。実際に攻撃を受けたAlpine Linux（アルパイン・リナックス）のGitLabでも、攻撃者はまず新しいアカウントを登録していました。

対象の版と、移る先

自社のサーバーに入れて使うGitLab（Community Edition・Enterprise Editionの両方）が対象です。GitLab.comとGitLab Dedicated（専用クラウド版）は、GitLab側で修正済みです。

系統	CVE-2026-97229の対象	最初の修正版	おすすめの移る先（10月29日時点）
19.5	記載なし	—	19.5.3以降
19.4	対象	19.4.2（10月12日）	19.4.5以降
19.3	対象	19.3.5（10月12日）	19.3.7以降
19.2	対象	19.2.8（10月12日）	19.2.10以降
19.1・19.0・18.11	別の10.0が対象	—	19.1.10／19.0.11／18.11.14以降
18.10以前	修正版なし	—	サポート中の系統へバージョンアップ

※19.1以前の系統は、CVE-2026-97229の対象には挙げられていません。ただし10月21日に直った別の脆弱性 CVE-2026-110264（同じく深刻度10.0）は、GitLab 7.0以降のほぼすべての版が対象です。古い版ほど、急いで更新が必要です。

※一部のニュースでは19.3系の修正版を「19.3.4」としていますが、GitLabの公式発表では19.3.5です。

GitLabを更新しても直らない場合があります

この脆弱性の本当の原因は、GitLabが使っている言語「Ruby」の、正規表現を処理する部分にありました。GitLabは公式パッケージ（Omnibus版や公式のDockerイメージなど）にだけ、Rubyの修正を組み込んでいます。

ソースコードから自分で組み立てたGitLabや、公式以外のコンテナを使っている場合は、Rubyも 3.3.13／3.4.12／4.0.9以降 に更新する必要があります。実際にAlpine LinuxはGitLabを更新したあとも脆弱なままで、10月25〜26日に再び攻撃を受けました。

これまでの流れ

2026年10月12日
GitLabが修正版（19.4.2／19.3.5／19.2.8）を公開
2026年10月13日
調査会社が攻撃の再現方法（PoC）を公開。この時点で約2.6万台のサーバーが更新前の版で動いていました
2026年10月20〜21日
Alpine LinuxのGitLabが攻撃を受ける
2026年10月21日
別の深刻度10.0の脆弱性（CVE-2026-110264）の修正版を公開。古い系統（18.11〜19.1）にも提供
2026年10月23日
Rubyが修正版（3.3.13／3.4.12／4.0.9）を公開
2026年10月29日
CISAが「悪用が確認された脆弱性」に追加。同じ日にGitLabが最新の修正版（19.5.3ほか）を公開

確かめて、対応する5ステップ

GitLabをどこで使っているか確認する
自社のサーバーやクラウド（AWSなど）に入れているのか、GitLab.comを使っているのかを確認します。ソースコードを開発会社に預けている場合は、その会社のGitLabかもしれません。
版を確認する
GitLabにログインし、左のメニューの下にある「ヘルプ」→「ヘルプ」を開くと、いちばん上に版（例：19.4.1）が出ます。
使っている系統の最新版に更新する
上の表の「おすすめの移る先」まで上げます。公式パッケージ以外で入れている場合は、Rubyの版も確認します。
攻撃を受けた形跡がないか調べる
更新の前後で、ログを確認します。CI設定の確認機能（lint）へのアクセスのあとに「502」エラーが出ていないか、GitLabの処理プログラムが急に再起動していないか、覚えのないユーザー登録がないか、などが目安です。
あやしい点があれば、鍵とパスワードを入れ替える
GitLabに保存しているパスワード、アクセス用の鍵（トークン）、本番サーバーのログイン情報を入れ替えます。Alpine Linuxは、サーバーを作り直し、全員のパスワードとGitLabの秘密の鍵を入れ替えました。

すぐに更新できないときの応急処置

だれでもユーザー登録できる設定をやめる、知らない人が公開プロジェクトを作ったり書き込んだりできないようにする、GitLabの画面に社外からつなげないようにする――などで、攻撃されにくくなります。ただし、これは弱いところそのものを直すものではありません。更新までのつなぎとして使ってください。