この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
GitLabのセキュリティパッチリリース「18.11.3 / 18.10.6 / 18.9.7」が2026年5月13日に公開されました。同梱CVEは25件、CVSS 8.7のXSS 4件とCVSS 7.5の未認証DoS 3件を含みます。JPCERT/CCも5月20日の週次レポートで取り上げており、self-managed（オンプレ）GitLabを社内に抱えている組織は後回しにできない案件です。GitLab.com（SaaS版）はGitLab側で適用済み、対応すべきは「自社で動かしているGitLab」のみです。本記事ではomnibus-gitlab運用エンジニア向けに、CVE群整理・影響判定・アップグレード実務・ゼロダウンタイム化・PG/Redis注意点・CI/CD継続性をまとめます。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
2026年5月のGitLabセキュリティリリースで何が直ったか
GitLab公式のパッチリリースノートに記載されているCVEのうち、運用上インパクトが大きいものを抜き出します。
CVSS 8.7のXSS 4件
4件すべて「認証済みユーザーによるXSS」です。攻撃の入口は以下の4箇所に分かれます。
- CVE-2026-7481：Analytics Dashboardのチャート描画。EE 16.4～18.11.2が影響範囲。
- CVE-2026-5297：グローバル検索フィールド。CE/EE 15.11～18.11.2と影響範囲が広い。
- CVE-2026-6073：Duo Agentの出力レンダリング。EE 18.7～18.11.2。
- CVE-2026-7377：別経路のAnalytics Dashboard XSS。EE 18.7～18.11.2。
GitLabのようなマルチユーザーかつ権限分離が複雑な基盤では、低権限ユーザーがメンテナや管理者のセッションを奪う踏み台になります。社内の開発者誰でもログインできる状態なら、実質「内部犯による管理者乗っ取り」のリスクとして扱う必要があります。
未認証DoS 3件
CVSS 7.5の未認証DoSが3件含まれている点も重要です。
- CVE-2026-1659：CI/CD job update APIへの未認証DoS。影響範囲がCE/EE 9.0～18.11.2と異常に長く、10年近く分のGitLabが射程に入ります。
- CVE-2025-14870：Duo Workflows APIへの未認証DoS。CE/EE 18.5～18.11.2。
- CVE-2025-14869：内部APIエンドポイントへの未認証DoS。CE/EE 18.5～18.11.2。
未認証で叩けてCI/CD APIにヒットするDoSが特に厄介です。GitLabのCI/CDはRunnerが頻繁にAPIを叩く前提なので、攻撃が成立するとビルドキューが詰まり開発組織全体が止まります。インターネット直公開のGitLabはもちろん、社内ネットワーク内でも、感染した端末1台から内側を叩けるなら同じです。
その他のCVE抜粋
CVE-2026-1322（CVSS 6.8、GraphQLトークンスコープ不適切）、CVE-2026-4524（6.5、Issues APIアクセス制御）、CVE-2026-4527（6.5、Jira連携CSRF）、CVE-2026-8280（6.5、CSV解析DoS、CE/EE 8.3～18.11.2と異常に長い）など、APIトークン・プロジェクト境界・連携機能に効くものが残りを占めます。
影響を受けるのはどんなGitLab環境か
影響を受けるかどうかは、「self-managedか」「バージョンが18.11.2以下か」の2点で判定できます。インストール方式や規模は問いません。
GitLab.com vs Self-Managedの影響範囲対比
| 環境 | 影響 | 対応 |
|---|---|---|
| GitLab.com（SaaS） | なし | GitLab側で適用済み、利用者は何もしない |
| self-managed CE/EE omnibus | あり | 18.9.7 / 18.10.6 / 18.11.3 のいずれかへ |
| self-managed Helm（K8s） | あり | 対応するチャートバージョンへ更新 |
| self-managed Docker | あり | 対応するタグへpull＋再起動 |
| self-managed source | あり | 同等バージョンのソースからビルド |
バージョン即時確認のコマンド
omnibus-gitlabが動いているLinuxサーバーで、まずバージョンを確定します。
# omnibus-gitlabの場合
sudo gitlab-rake gitlab:env:info | grep "GitLab information" -A 5
# またはAPI経由（管理者トークンで）
curl --header "PRIVATE-TOKEN: " "https://gitlab.example.com/api/v4/version"
# パッケージレベルでの確認
dpkg -l | grep gitlab-ce # Debian/Ubuntu系
rpm -qa | grep gitlab-ce # RHEL/AlmaLinux/Rocky系
「GitLab 18.11.2」「18.10.5」「18.9.6」以前なら影響範囲です。これより古い「17系」「16系」を運用しているなら、複数バージョンを跨ぐ大規模アップグレードが必要になります。
omnibus-gitlabでのアップグレード手順
omnibus-gitlabは「OSのパッケージ管理経由でアップグレードできる」のが最大の利点ですが、状態を持つアプリ（PostgreSQL、Redis、Gitalyの内部状態）なので、単純なyum updateとは段取りが違います。
1. アップグレード前の完全バックアップ
必ず以下3点を順に取ります。STRATEGY=copyを付けないと「バックアップ中にGitプッシュが入り、tar取得時に整合性が壊れる」事故が起きます。
# 1. データバックアップ（リポジトリ・DB・添付・LFS・レジストリ）
sudo gitlab-backup create STRATEGY=copy
# 2. 設定ファイルバックアップ（/etc/gitlab配下）
sudo gitlab-ctl backup-etc
# 3. 念のためサーバー全体のスナップショット（VM・LVMスナップショット等）
2. アップグレードパスの確認
| 現バージョン | 推奨パス | 注意点 |
|---|---|---|
| 18.11.x / 18.10.x / 18.9.x | 同マイナーの最新（18.11.3 / 18.10.6 / 18.9.7）へ直接 | 最も低リスク |
| 18.0～18.8 | 段階アップグレード後に18.9.7 | required stopが入る可能性、公式パス計算ツール確認必須 |
| 17.x以前 | 17.x最新→18.0→18.9.7 | メジャー跨ぎはバックグラウンドマイグレーション完了待ち |
3. omnibus-gitlabのアップグレードコマンド
Debian/Ubuntu系・RHEL系どちらも、バージョンを明示してインストールします。明示しないと「リポジトリの最新」に上がってしまい、本番では想定外バージョンに化ける事故が起きます。
# Debian/Ubuntu系（CE 18.11.3の場合）
sudo apt-get update
sudo apt-get install gitlab-ce=18.11.3-ce.0
# EEの場合: gitlab-ee=18.11.3-ee.0
# RHEL系（AlmaLinux 9 / Rocky 9）
sudo dnf install gitlab-ce-18.11.3-ce.0.el9.x86_64
4. PostgreSQL/Redis周りの注意
omnibus-gitlabはPostgreSQLとRedisを内蔵しています。GitLab 18系のサポートPGバージョンは14/15/16で、内部PGのメジャーが上がる場合は `gitlab-ctl pg-upgrade` が走り停止時間が伸びます。外部PostgreSQLを使っているHA構成では、アップグレード対象に外部PGも含まれます。本体だけ上げてPGを取り残すと後続パッチで弾かれます。内蔵Redisは7.0系が推奨で、Sentinel冗長化時はmaster/replica全台のバージョンを揃える必要があります。
# 内部PostgreSQLのバージョン確認
sudo gitlab-psql -c "SELECT version();"
# PG単独のアップグレード（必要時）
sudo gitlab-ctl pg-upgrade
ゼロダウンタイムアップグレードとロールバック
「平日昼間にgitlab-ctl stopして上げる」はもう許されない、という現場が増えています。HA構成（HAProxy/Nginx＋Railsアプリ複数台、Patroni＋PgBouncerでPGクラスタ、Sentinel構成のRedis、Praefect配下のGitaly）を組んでいれば、Railsアプリを1台ずつLBから外してアップグレード→戻す、を繰り返してゼロダウンタイム化できます。データベース層のマイグレーションは「post-deployment migration」として後追いで走らせる仕組みがあり、マイグレーション中もサービス継続が可能です。
ロールバック手順
失敗時のロールバックは「同じマイナー内の前バージョンに戻す」が原則です。バージョンを跨ぐロールバックはPostgreSQLスキーママイグレーションの非可逆性により極めて危険です。
# バックアップから戻す（ロールバック）
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
sudo gitlab-backup restore BACKUP=
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
ロールバック未想定の現場が、本番停止状態でこの手順を初めて読むのが事故の典型パターンです。バックアップ戦略全般についてはLinuxサーバーのバックアップを「あとでやろう」と先送りしていた自分が障害で学んだことでも触れていますが、「取れるか」より「戻せるか」が本質です。
CI/CDパイプライン継続性の確保
GitLab本体を上げるとき、CI/CD Runnerと走行中Jobをどう扱うかが地味に難所です。まず全Runnerをpaused状態へ（走行中Jobは完走、新規は流れない状態）。Runner本体のバージョン差は3マイナー以内に維持。`.gitlab-ci.yml` に `retry: 2`（`runner_system_failure` / `api_failure`条件）を入れて失敗Jobを自動リトライ吸収。この3点だけ押さえてあれば、アップグレード中の事故は大幅に減ります。
# 全Runnerを一時的にpaused状態へ
curl --request PUT --header "PRIVATE-TOKEN: " \
"https://gitlab.example.com/api/v4/runners/" \
--data "paused=true"
FAQ
Q1. 自社のGitLabがSelf-Managedか自信がない。どう確認するか？
URLがgitlab.com以外（gitlab.example.co.jpのような自社ドメイン）なら、ほぼ間違いなくSelf-Managedです。心配なら、`gitlab-rake gitlab:env:info` を実行できる権限が誰かにあるかで判定できます。SaaSなら社内でそのコマンドは実行できません。
Q2. 18.0より前の17系/16系を運用している。順序は？
メジャー間にrequired stopが定義されているケースがあり、「17系最新→18.0→18.9.7」のような段階アップグレードが必要です。公式のアップグレードパス計算ツールで対象バージョンを入力し、必須経由ポイントを確定してから動きます。1日でメジャー2つ跨ぐのは無理だと割り切る必要があります。
Q3. CI/CDを止めずに本体だけ上げたい。可能か？
HA構成があれば可能です。Railsアプリを1台ずつLBから外してアップグレードし、Runnerはpaused→Job完走→アップグレード、で止めずに進められます。単一サーバー構成では原則不可能で、メンテナンスウィンドウを取るしかありません。
Q4. 未認証DoS（CVE-2026-1659）の即時対策はパッチ以外にあるか？
暫定策として、CI/CD job update APIエンドポイント（`/api/v4/jobs/request`等）の前段にWAFまたはNginxレベルでレートリミットをかけることで緩和できます。ただしJob数が多い環境では正常Runnerの通信もブロックする可能性があり、パッチ適用が最も確実です。
Q5. アップグレード後の終了判定は？
最低限、`gitlab-rake gitlab:env:info` のバージョン確定、`gitlab-rake gitlab:check` のエラーゼロ、サンプルプロジェクトでのclone/push/CI Job疎通、管理画面のバックグラウンドマイグレーションがFinished、`/var/log/gitlab/` のERRORゼロ、の5点を確認します。
運用チェックリストとまとめ
- [ ] 自社GitLabがSelf-Managedかを確認した
- [ ] 現バージョンを `gitlab-rake gitlab:env:info` で確定した
- [ ] アップグレード対象（18.9.7 / 18.10.6 / 18.11.3）を決めた
- [ ] 完全バックアップ（STRATEGY=copy）と設定バックアップ（backup-etc）を取得した
- [ ] ステージング環境で同じ手順を1回流して検証した
- [ ] HA構成ならローリング手順、単一構成ならメンテ窓を確保した
- [ ] ロールバック手順書を準備した
- [ ] アップグレード後の確認項目（FAQ Q5）を満たした
GitLabのアップグレードはLinuxサーバーの単純な脆弱性パッチよりも段取りが多く、最初の1回で詰まりやすい部分があります。私自身、20年以上Linuxの現場でサーバーを触ってきましたが、状態を強く持つ基盤はyum updateと同じノリで進めるとどこかで必ず詰まります。頼りになるのは、普段から「バックアップ→ステージング検証→ロールバック手順」を回しているかどうかの一点です。Gitそのものの基本はLinuxでGitを使う入門でも整理しています。
PR
GitLabのインストールから運用・CI/CD構築まで一冊で押さえられる定番書。アップグレード戦略やバックアップ設計といった、CVE対応の前提になる「平時の運用設計」を体系化したい方に向いています。
Linuxサーバー運用とセキュリティを体系的に学びたい方へ
リナックスマスター.JPでは、GitLabのようなOSS基盤を含むLinuxサーバー運用と、CVE対応・脆弱性管理の実務を、メールマガジンとハンズオンセミナーで学べます。「CVE速報を読むだけ」から「自分の現場で当てる側」へ移るための、実践的なカリキュラムを揃えています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます