CVE-2026-110264 GitLab｜修正版の選び方と侵害確認

はじめに

2026 年 10 月 21 日、GitLab は Community Edition（CE）と Enterprise Edition（EE）向けに臨時のセキュリティリリース（Critical Patch Release）を公開しました。修正対象は 12 件で、このうち CVE-2026-110264 は CVSS 10.0 の認証不要なリモートコード実行（RCE）につながる可能性がある脆弱性です。

GitLab は 10 月 12 日にも CVSS 10.0 の CVE-2026-97229 を修正したばかりです。そのため「先週更新したので対応済み」と判断してしまう、旧系列向けの個別修正だけで 12 件すべてが直ったと誤解する、Helm chart のバージョン番号を GitLab 本体の番号と比較してしまう、といった判断ミスが起こりやすい状況です。

結論として、Self-Managed の GitLab は、10 月 12 日の修正版（19.4.2 / 19.3.5 / 19.2.8）を適用済みでも CVE-2026-110264 の影響を受けるため、19.5.1 / 19.4.3 / 19.3.6 のいずれかへの更新が必要です。19.2 以前の系列向けに用意された 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13 は CVE-2026-110264 の修正を含みますが、同時に公表された他の脆弱性は修正対象外のため、暫定措置として扱い、保守対象の系列への移行を計画してください。GitLab.com は公式発表時点で修正済みです。

GitLab の CVE-2026-110264 とは

CVE-2026-110264 は、正規表現のコンパイル時に発生する整数オーバーフローの脆弱性です。対象は GitLab CE / EE の両方で、影響範囲は GitLab 7.0 以降の全系列に及びます。

脆弱性の概要と公式に確認できる発生条件

GitLab のリリースノートと CVE レコードは、特定の条件下で、細工された正規表現のコンパイル時に整数オーバーフローが発生し、認証されていないユーザーが GitLab サーバー上で任意のコードを実行できる可能性があると説明しています。CWE は CWE-190（整数オーバーフロー）です。

参考: 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
“an unauthenticated user to execute arbitrary code on the GitLab server”
（認証されていないユーザーが GitLab サーバー上で任意のコードを実行できる可能性がある）
https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/

リリースノートの脆弱性説明そのものは、どの機能を経由して細工された正規表現が処理されるかを明記していません。一方、GitLab のセキュリティチームが同時に公開した検知ルール（TLDR）の資料では、リポジトリ内の Org mode ファイル（.org）を描画する処理が経路として示されています。同資料は、パッチ適用までの間は公開範囲を可能な範囲で縮小することも挙げています。

公開情報だけでは、次の点は断定できません。

• リリースノートの「特定の条件下」が具体的にどの設定・構成を指すか
• Org mode の描画以外に同じ不具合へ到達する経路があるか
• 公開プロジェクトを持たない、または外部に公開していないインスタンスで、リスクがどの程度下がるか

GitLab は回避策を示していないため、公開範囲の縮小は更新までの補助的な措置と考え、更新そのものを優先してください。

CVSS 10.0 と悪用状況は別の情報

CVSS 10.0（CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）は、成立した場合の影響の大きさと攻撃条件の評価であり、実際に悪用されているかを示す値ではありません。2026 年 10 月 22 日時点で確認できた状況は次のとおりです。

「悪用が確認されていない」ことは「安全である」ことを意味しません。攻撃コードの公開、攻撃の観測、KEV への掲載はそれぞれ別の事象として、更新後も継続して確認してください。

10 月 12 日の CVE-2026-97229 との違い

2 つの脆弱性は CVSS ベクトルが同一ですが、別の CVE として公表され、修正版も異なります。

GitLab の検知ルール資料は、両者とも Ruby の正規表現エンジン（Onigmo）に関わるものの、入力経路が異なる（CVE-2026-97229 は CI/CD 設定、CVE-2026-110264 は Org mode の描画）と説明しています。リリースノート上の修正内容も別の項目として記載されており、一方の修正で他方が解消される関係ではありません。

19.4.2 / 19.3.5 / 19.2.8 を適用した直後の環境も、CVE-2026-110264 の影響範囲に含まれます。10 月 12 日の対応記録を「今回も対応済み」の根拠に使わないよう注意してください。

GitLab の影響バージョンと修正版の選び方

更新先は、現在の系列と、12 件すべてを修正したいか、CVE-2026-110264 だけを当面解消するかで変わります。

系列別の修正版と残る脆弱性

他の 11 件の影響範囲は「19.3.6 未満」「19.4 系の 19.4.3 未満」「19.5 系の 19.5.1 未満」と記載されており、影響開始バージョンは CVE ごとに異なります。たとえば 19.2.9 へ更新しても、CVE-2026-15723 や CVE-2026-112212 などは修正されません。

Helm chart は GitLab 本体とバージョン番号が異なります。特に 19.3 系列は、chart 10.3.6 が GitLab 19.3.5（CVE-2026-110264 の影響あり）、chart 10.3.7 が 19.3.6（修正版）に対応しており、末尾の数字だけで比較すると判断を誤ります。必ず公式の対応表で確認してください。

旧系列へのバックポートの注意点

GitLab の保守ポリシーでは、セキュリティ修正のバックポート対象は現行の安定版と直近 2 つのマイナーリリースです。執筆時点の保守対象は 19.5 / 19.4 / 19.3 で、19.2.9 / 19.1.9 / 19.0.10 / 18.11.13 は CVE-2026-110264 のために例外的に用意された個別修正です。

参考: GitLab release and maintenance policy
“Backporting security fixes to the previous two monthly releases”
（セキュリティ修正は直近 2 つの月次リリースへバックポートする）
https://docs.gitlab.com/policy/maintenance/

旧系列の個別修正は、アップグレードパスの準備が間に合わない場合に CVE-2026-110264 を先に解消する手段として有効です。ただし、今後のセキュリティ修正が同じ系列へ提供される保証はないため、個別修正を適用した後も、19.3 以降の保守対象系列への移行を計画してください。

GitLab.com / Dedicated / Self-Managed の違い

GitLab.com

公式発表時点で修正済みのバージョンで稼働しています。利用者側の更新作業は不要です。

GitLab Dedicated

19.3.5-internal0 および 19.4.2-internal0 以降で稼働しているテナントは修正を含み、対応は不要と公式に記載されています。

Self-Managed（Linux package / Docker / Helm chart）

管理者による更新が必要です。リリースノートは、導入方式が明記されていない場合はすべての方式が影響を受けるとしています。確認・バックアップ・更新のコマンドは導入方式ごとに異なります。

同時に修正された 11 件の GitLab 脆弱性

CVE-2026-110264 以外の 11 件は、認証基盤や内部認証情報、アクセス制御に関わるものが中心です。実務上の優先度が高い 2 件を先に解説し、残りは一覧で整理します。

認証基盤に関わる CVE-2026-15723 と CVE-2026-112212

CVE-2026-15723（CVSS 8.2）は、OmniAuth の SAML と LDAP の自動アカウント連携が両方有効な環境に限定される脆弱性です。OmniAuth のアカウント連携時に使う LDAP のメールアドレス検索で入力の無害化が不十分なため、認証済みユーザーが、対象ユーザーの操作なしに既存の LDAP アカウントを乗っ取れる可能性があります。影響範囲は 10.1 以降です。

SAML と LDAP を併用している企業では、ユーザー設定ファイル（Linux package では /etc/gitlab/gitlab.rb）の OmniAuth と LDAP の設定を確認し、SAML プロバイダーの設定と LDAP 自動連携が両方有効かを確認してください。いずれかを使用していない環境では成立条件を満たしませんが、他の脆弱性もあるため更新判断は変わりません。両方を有効にしている場合は、更新後に LDAP 連携アカウントの紐付けやサインイン履歴に不自然な変更がないかも確認することをおすすめします。

CVE-2026-112212（CVSS 7.5）は、OAuth / OIDC のディスカバリー文書（認可エンドポイントなどの URL を返す応答）が共有キャッシュに保存される場合に、認証されていないユーザーがその内容を汚染し、一部の認証フローを外部の攻撃者管理サーバーへ誘導できる可能性がある脆弱性です。影響範囲は 18.3 以降です。

CVSS ベクトルは AC:H（攻撃の複雑さ: 高）と UI:R（ユーザーの操作が必要）で、公式説明も「特定の条件下で」としています。共有キャッシュの具体的な構成は公開されていないため、GitLab の前段にリバースプロキシや CDN などのキャッシュを置いている場合は、GitLab の応答をキャッシュしていないか、キャッシュキーの設定とあわせて確認してください。GitLab を OAuth / OIDC のプロバイダーとして他システムの認証に利用している環境では、影響を受ける連携先も洗い出しておくことをおすすめします。

今回修正された 12 件の一覧

影響開始バージョンは CVE ごとに異なります。いずれも修正版は 19.5.1 / 19.4.3 / 19.3.6 で、旧系列向けの個別修正に含まれるのは CVE-2026-110264 のみです。

企業運用の観点では、認証基盤（CVE-2026-15723、CVE-2026-112212、CVE-2026-16255）、内部認証情報（CVE-2026-105777）、トークンのスコープ制御（CVE-2026-12664）、マージリクエストの承認制御（CVE-2026-14288）が、統制やコンプライアンスに直結する項目です。

なお、CVE-2026-105777 は、リリースノートと CVE レコードの説明文がいずれも「認証されていないユーザー」としている一方、CVSS ベクトルは PR:L（低い権限が必要）です。2026 年 10 月 22 日時点で両者の差異を解消する公式の説明は確認できませんでした。認証不要で悪用される可能性を否定できないため、CVSS 4.3 だけで優先度を下げないことをおすすめします。

GitLab アップデートの手順と確認ポイント

GitLab は、最新版を上書きインストールすれば完了するとは限りません。必ず経由するバージョン（Required upgrade stops）、バックグラウンドマイグレーションの完了、CI/CD ジョブへの影響、バックアップの復元条件を確認したうえで更新してください。

提供形態と稼働バージョンの確認

Self-Managed と Dedicated では、サインイン後に左サイドバー下部の Help > Help を開くと、ページ上部にバージョンが表示されます。GitLab.com では https://gitlab.com/help で確認できます。

Linux package では、GitLab Rails が稼働するノードで次のコマンドを実行すると、出力の「GitLab information」に Version が表示されます。マルチノード構成では Rails ノード以外で実行しないでください。

sudo gitlab-rake gitlab:env:info

Helm chart では、まず GitLab をデプロイした名前空間で稼働中のリリースを確認します。出力の CHART 列に gitlab-10.3.7 のような形式で chart 名とバージョンが表示されます。名前空間が不明な場合は -A（全名前空間）を指定できます。

helm list -n <namespace>

次に、確認した chart バージョンを公式の対応表に当てはめ、GitLab 本体のバージョンに換算してから修正版と比較します。対応表は次のコマンドでも一覧表示できます（出力されるのはリポジトリ上で利用可能な chart の一覧で、稼働中のバージョンではありません）。

helm repo add gitlab https://charts.gitlab.io/
helm search repo -l gitlab/gitlab

参考: Find the GitLab version、Maintenance Rake tasks、GitLab Helm chart versions、helm list

更新前後の実務チェックリスト

sudo gitlab-rake gitlab:check
sudo gitlab-rake gitlab:doctor:secrets

sudo gitlab-backup create

docker exec -t <container name> gitlab-backup create

CVE-2026-110264 の侵害兆候を確認する方法

更新は今後の悪用を防ぐ作業で、過去に侵害されたかどうかは別途確認する必要があります。GitLab セキュリティチームは、Self-Managed 環境向けに 2 つの検知ルールを TLDR（Threat, Logs, Detection, Respond）として公開しています。各ルールは Sigma 形式で提供され、SIEM がない環境向けのログ検索例も含まれます。

公式検知ルールの対象と必要なログ

SIEM へ取り込んでいない環境では、まず各ログがサーバー上に残っている期間を確認してください。Linux package でネイティブクラッシュの記録があるかを簡易的に確認するには、次のコマンドが利用できます。該当行があれば、前後のバックトレースを公式ルールの条件と照合します。

sudo grep -n '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log*

参考: TLDR Vulnerability Detections（GitLab Security）、Security incident detection

検知結果から断定できること、できないこと

公式ルールの資料は、攻撃が成功した場合は静かでクラッシュを伴わないことがあると説明しています。検知ルールに該当しないことは、侵害がなかったことの証明になりません。逆に、該当した場合も攻撃の試行を強く示唆するにとどまり、それだけで侵害の成功は確定しません。

該当があった場合や、更新前に外部へ公開していた場合は、公式資料に沿って次の観点で調査することをおすすめします。

• 再起動やローテーションの前に、クラッシュレポートと関連ログ（application_json.log、exceptions_json.log、Workhorse のログ）を証拠として保全する
• Puma や Sidekiq の想定外の子プロセス、/tmp にある git ユーザー所有の不審なファイル、想定外の外部通信を確認する
• git ユーザーの crontab や SSH 鍵に変更がないか確認する
• 描画された .org ファイルを特定し、誰がいつコミットまたはアップロードしたかを確認する

コード実行の痕跡が見つかった場合、公式資料はインスタンスを侵害されたものとして扱い、gitlab-secrets.json の Secrets、すべての CI/CD 変数、Runner トークン、アクセストークンをローテーションするよう示しています。更新作業とは別に、組織のインシデント対応手順に沿って進めてください。

まとめ

CVE-2026-110264 は GitLab 7.0 以降の全系列が対象となる CVSS 10.0 の脆弱性で、10 月 12 日の修正版も影響を受けます。Self-Managed では保守対象の系列の修正版へ更新し、更新とは別に公式の検知ルールで過去の侵害兆候を確認してください。

• 19.4.2 / 19.3.5 / 19.2.8 を適用済みでも再更新が必要です。
• 12 件すべてを修正するには 19.5.1 / 19.4.3 / 19.3.6 が必要です。
• 19.2 以前向けの個別修正は CVE-2026-110264 のみが対象です。
• Helm chart は対応表で GitLab のバージョンに換算して比較します。
• 経由点、マイグレーション完了、Secrets のバックアップを確認します。
• 検知ルールの非該当は、侵害がなかったことの証明になりません。

以上、最後までお読みいただきありがとうございました。