GitLabの脆弱性CVE-2026-110264（CVSS 10.0）｜影響を受けるバージョンと直ったバージョン、更新のしかた

GitLabは2026年10月21日付けで、ログインしていない人にサーバー上で任意のコードを実行されるおそれがある脆弱性CVE-2026-110264（深刻度Critical、CVSS 10.0）を直した19.5.1・19.4.3・19.3.6・19.2.9・19.1.9・19.0.10・18.11.13を出しました。自分でGitLab（Self-Managed、CE・EEとも）を動かしている人は、使っているバージョンを確かめ、同じ系統の直ったバージョンにすぐ上げてください。GitLab.comはすでに対応済みで、利用者がすることはありません。

結論：自分で動かしているGitLabは、同じ系統の直ったバージョンにすぐ上げる

• 何が起きたか（深刻度Critical、CVSS 10.0）：特別な形の正規表現を処理するときに整数のオーバーフローが起き、条件によっては、ログインしていない人がGitLabのサーバー上で任意のコードを実行できるおそれがありました
• 影響を受けるもの：GitLab CE・EEの7.0以降で、直ったバージョンより前のものすべて。デプロイの種類（Linuxパッケージ・Docker・Helmチャート・ソースなど）は問いません
• 直ったバージョン：19.5.1・19.4.3・19.3.6・19.2.9・19.1.9・19.0.10・18.11.13
• 影響を受けないもの：GitLab.comはすでに直ったバージョンで動いています。GitLab Dedicatedは、19.3.5-internal0・19.4.2-internal0以降で直っていて、することはありません
• 気をつけること：19.4.3と19.3.6にはデータベースの移行（マイグレーション）があり、1台で動かしているGitLabは、更新中に止まります

影響を受けるバージョンと直ったバージョン

GitLabのパッチリリースのお知らせによると、次のとおりです。

GitLabの保守の決まり（メンテナンスポリシー）で今修正を出す対象になっているのは、19.5（バグとセキュリティの修正）と19.4・19.3（セキュリティの修正）です。GitLabは、それに加えて、この脆弱性の修正だけを18.11.13・19.0.10・19.1.9・19.2.9にも入れたとしています。

自分のGitLabのバージョンを確かめる

ブラウザでは、GitLabにログインし、左のサイドバーの下にある「ヘルプ」>「ヘルプ」を選ぶと、ページの上にバージョンが出ます。サーバーでは、次のコマンドの「GitLab information」の「Version」で確かめられます。

Linuxパッケージ（Omnibus）で入れている場合：

sudo gitlab-rake gitlab:env:info

Dockerで動かしている場合（コンテナ名が gitlab のとき）：

sudo docker exec -it gitlab gitlab-rake gitlab:env:info

更新のしかた

更新の前に

• Linuxパッケージで入れている場合は、新しいバージョンを入れる前にデータベースのバックアップが自動で取られます。それとは別に、自分でも最新の完全なバックアップ（シークレットのファイル /etc/gitlab/gitlab-secrets.json と設定のファイル /etc/gitlab/gitlab.rb を含む）を持っておくよう、GitLabは求めています。Dockerの場合は、下の「Docker」の手順で、自分でバックアップを取ります
• 1台で動かしているGitLabは、19.4.3・19.3.6に上げるとき、データベースの移行が終わるまで起動しません。止まってもよい時間に作業します。複数台の構成は、停止なしの更新の手順に沿えば止めずに上げられます
• GitLabは、更新の間はメンテナンスモードにすることを考え、動いているCI/CDのパイプラインとジョブを止めるよう案内しています。GitLab Runnerも、GitLabと同じバージョンに上げます

Linuxパッケージ（Ubuntu・Debian）

使っている系統の直ったバージョンを指定して入れます。19.5の例です。

# GitLab Enterprise Edition
sudo apt update && sudo apt install gitlab-ee=19.5.1-ee.0
# GitLab Community Edition
sudo apt update && sudo apt install gitlab-ce=19.5.1-ce.0

Linuxパッケージ（RHEL・AlmaLinux・Oracle Linux 9）

# GitLab Enterprise Edition
sudo dnf install gitlab-ee-19.5.1-ee.0.el9
# GitLab Community Edition
sudo dnf install gitlab-ce-19.5.1-ce.0.el9

8系では、末尾の el9 を el8 にします。ほかの系統では、19.5.1 を上の表の直ったバージョンに置き換えます。

Docker

公式のイメージには、直ったバージョンのタグ（例：gitlab/gitlab-ee:19.5.1-ee.0、gitlab/gitlab-ce:19.5.1-ce.0）が出ています。

まず、バックアップを作ります。GitLabは、少なくともデータベースとシークレットのファイルをバックアップするよう求めています。シークレットのファイルは、コンテナの中の /etc/gitlab/gitlab-secrets.json、ホストでは $GITLAB_HOME/config/gitlab-secrets.json にあります。データベースだけのバックアップは、次で作れます（コンテナ名が gitlab のとき）。

sudo docker exec -t gitlab gitlab-backup create SKIP=artifacts,repositories,registry,uploads,builds,pages,lfs,packages,terraform_state

バックアップは、コンテナの中の /var/opt/gitlab/backups にできます。ここがDockerのボリュームになっているかを確かめておきます。

Docker Composeで動かしている場合

docker-compose.yml の image を直ったバージョンにします。

image: gitlab/gitlab-ee:19.5.1-ee.0

そのうえで、イメージを取り直してコンテナを作り直します。

docker compose pull
docker compose up -d

docker runで動かしている場合

コンテナを止めて消し、直ったバージョンのイメージを取ってから、前と同じオプションで docker run を実行してコンテナを作り直します。データはボリュームに残ります。

sudo docker stop gitlab
sudo docker rm gitlab
sudo docker pull gitlab/gitlab-ee:19.5.1-ee.0

CEは gitlab/gitlab-ce:19.5.1-ce.0 です。作り直す前に、GITLAB_HOME が前と同じ場所を指しているかを確かめます。

echo $GITLAB_HOME

上げたあと

もう一度バージョンを確かめ、GitLabが求める確認（ヘルスチェック）として、全体の設定を確かめます。そのあと、メンテナンスモードにしていれば外し、止めたパイプラインを動かします。

Linuxパッケージの場合：

sudo gitlab-rake gitlab:env:info
sudo gitlab-rake gitlab:check

Dockerの場合：

sudo docker exec -it gitlab gitlab-rake gitlab:env:info
sudo docker exec -it gitlab gitlab-rake gitlab:check

18.10以前を使っている場合

18.10以前には直ったバージョンが出ていないので、18.11.13以降まで上げます。GitLabの更新は、途中で必ず通るバージョン（必須の停止点）があり、一気に最新まで上げられないことがあります。GitLab 17.5以降では、必須の停止点は x.2.z・x.5.z・x.8.z・x.11.z です。停止点まで上げたら、そのつどバックグラウンドの移行がすべて終わるのを待ってから、次の停止点へ上げます。GitLabは、どの更新の前にも、すべての移行が終わっていることを求めています。移行の状態は、GitLab 18.9以降では sudo gitlab-rake gitlab:background_migrations:list、18.8以前では sudo gitlab-rake gitlab:background_migrations:status で見られます（Dockerでは sudo docker exec -it gitlab gitlab-rake gitlab:background_migrations:list のようにします）。どの順で上げるかは、GitLabのUpgrade Path toolで確かめられます。GitLabは、各マイナーバージョンでは最初のパッチではなく最新のパッチリリースに上げるよう求めています。

同じパッチで直ったほかの脆弱性

今回のパッチリリースでは、CVE-2026-110264のほかに11件が直っています。こちらは19.5.1・19.4.3・19.3.6だけで直り、18.11.13・19.0.10・19.1.9・19.2.9には入っていません。19.2以前の系統を使っている人は、CVE-2026-110264を直したあと、ふだんのパッチリリースの対象になっている19.3以降へ上げる計画も立てます。

よくある質問

GitLab.comを使っているだけなら、何かする必要はありますか

ありません。GitLabは、GitLab.comはすでに直ったバージョンで動いているとしています。

攻撃を受けたか確かめる方法はありますか

GitLabのセキュリティチームは、Self-Managedの利用者向けに、この脆弱性をねらった試みを見つけるための検知ルールを2つ公開しています（「Onigmo native worker crash」と「Org mode render error burst」）。くわしくはGitLabのパッチリリースのお知らせから、それぞれのページを見てください。

脆弱性のくわしい中身はいつ出ますか

GitLabは、セキュリティの修正の詳しい課題（issue）を、修正を出してから90日後に公開するとしています。

参考リンク

• GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13（GitLab Docs）
• Upgrade Linux package instances（GitLab Docs）
• Upgrade paths（GitLab Docs）
• Install GitLab in a Docker container（GitLab Docs）
• Maintenance Rake tasks（GitLab Docs）
• Upgrade Docker instances（GitLab Docs）
• Back up GitLab running in a Docker container（GitLab Docs）
• Before you upgrade（GitLab Docs）
• Check migrations before upgrade（GitLab Docs）
• Find the GitLab version（GitLab Docs）
• GitLab release and maintenance policy（GitLab Docs）