Gitの脆弱性6件：CVE-2026-111760の再帰クローン対策と2.56.1への更新手順

Gitのメンテナーは2026年11月10日、6件の脆弱性を直したGit 2.56.1と、2.50.2〜2.55.1の修正版を公開しました。最も重いCVE-2026-111760は、細工したリポジトリを--recurse-submodules付きでクローンすると、攻撃者のコードが動くという問題です。この記事では、6件の中身、使っている系列の修正版、開発端末・CIランナー・リポジトリを扱うサーバーで版を確かめる方法、更新まで再帰クローンを止める設定を、2026年11月14日時点の一次情報で整理します。

まとめ：開発端末とCIのGitを2.56.1系の修正版へ上げ再帰クローンを止める

最初にやることは、Gitが入っている場所の洗い出しです。開発者のPCだけでなく、CIのランナー、デプロイ用のサーバー、GitLabのようなリポジトリ管理サーバー、Gitを同梱するアプリまで数えます。それぞれでgit --versionを見て、2.56.1か、使っている系列の修正版（2.55.1・2.54.1・2.53.1・2.52.1・2.51.3・2.50.2）に上げます。

更新が終わるまでは、外部のリポジトリやフォークからのプルリクエストを--recurse-submodulesで取り込まないようにします。Debianの標準パッケージのように、配布元の修正がまだ届いていない環境もあります。

CIや社内サーバーが多く、どこに古いGitが残っているか把握しきれない場合は、脆弱性診断・セキュリティ診断で開発基盤の棚卸しから始めると漏れが出にくくなります。

2026年11月10日公表のGit脆弱性6件：再帰クローンでの実行とマージ時のヒープ破壊

修正を書いたElijah Newren氏によるGitHub公式ブログの発表をもとに影響の大きさで分けると、手元でコードが動く1件、サーバー側でコマンド実行につながる1件、ファイル書き込みや情報の読み取り・異常終了につながる4件です。

CVE-2026-111760：submoduleのgitfile置換によるコード実行

GHSA-vp2w-7xxj-jvxrによると、深刻度はHigh、CVSS 3.1の基本値は8.0です。細工したリポジトリをクローンさせると、submoduleが使う.gitファイル（gitfile）が、攻撃者の設定やフックを置いたディレクトリへのシンボリックリンクに置き換わります。その設定やフックを通じてコードが実行されます。

原因は、インデックスを扱う処理での整数の切り捨てです。極端に長いパスが安全確認を通ったあと、短い名前でディスクへ書かれます。修正版での対処は、長すぎるパスをディスクへの書き込み前に拒否することです。GHSAは、現時点で問題が起きるのは--recurse-submodulesを使ったときだけとしています。

CVE-2026-105437：大量コンフリクトのマージによるヒープ破壊

マージ結果を入れるバッファの大きさを計算するとき、値があふれる問題です。大量のコンフリクトと大きなconflict-marker-sizeを組み合わせるとバッファが小さく確保され、その前後に書き込んでヒープを壊します。

手元の端末なら異常終了で済む場面が多いものの、サーバーでマージを実行する製品では影響が変わります。GitLabの2026年11月10日のパッチリリースは、この問題でGitaly環境内の任意コマンド実行につながるとして、深刻度をCriticalとしました。

残る4件の発生条件：HEAD・タグ署名・バイナリパッチ・fast-import

残りの4件は、Git 2.50.2のリリースノートに説明があります。

CVE-2026-113408は、サーバーがrefs/heads/../../../TARGETのようなHEADを通知できた問題です。CVE-2026-114466の修正では、fast-importのrewrite-submodules-to・rewrite-submodules-from・export-pack-edgesが既定で無効になりました。移行ツールでこれらを使っているなら、入力元を信頼できる場合に限って--allow-unsafe-featuresを付けます。

Git本体・Git for Windows・Linuxパッケージの修正版と配布状況

Gitは複数の系列を並行して保守しています。最新の2.56系へ上げなくても、使っている系列の修正版で6件とも直ります。

2.56.1と2.50.2〜2.55.1の7系列：使っている系列の修正版を選ぶ表

Git 2.56.1のリリースノートは、2.50.2・2.51.3・2.52.1・2.53.1・2.54.1・2.55.1の修正を取り込んだと書いています。

2.49以前の系列には、Gitプロジェクトとしての修正版が出ていません。Debian bookwormの2.39系のように古い系列を使う環境は、配布元が修正を戻すのを待つか、新しい系列のGitを別に入れることになります。

GHSAの修正版欄がnoneのままでもリリースノートとGitHub公式発表で判断

2026年11月14日時点で、GHSA-vp2w-7xxj-jvxrの修正版の欄は「none」のままで、修正パッチはgit-securityメーリングリストで検討中という記述も残っています。一方で、2.56.1のリリースノートとGitHub公式ブログは、CVE-2026-111760を修正済みとしています。

脆弱性スキャナーがGHSAの欄だけを読むと、2.56.1に上げても「未修正」と出る可能性があります。私たちは、修正版に上げたかどうかはリリースノートとGitHub公式ブログで判断し、スキャナーの結果は例外として記録する扱いを勧めます。

Debianのbookworm〜sid標準パッケージ：2026年11月14日時点で未修正

Debianのセキュリティトラッカーでは、2026年11月14日時点でbookworm（2.39.5）、trixie（2.47.3）、forky（2.53.0）、sid（2.55.0）のいずれもvulnerableです。パッケージの版番号だけでは判断できず、配布元が修正を戻した場合は、版の数字が古いまま直ることがあります。

WindowsはGit for Windows 2.56.1が11月10日に出ていて、6件すべてを修正済みです。OSごとの更新コマンドはGitの最新バージョンの確認とOS別のアップデート方法、Windowsの配布物の選び方はGit for Windowsのダウンロード・インストール手順で扱っています。

開発端末・CIランナー・リポジトリ処理サーバーで版を確かめるコマンド

同じ人のPCでも、ターミナルのGit、IDEが使うGit、WSLの中のGitが別々に入っていることがあります。確かめるのは「どのGitが実際に呼ばれているか」です。

git –versionの出力から系列ごとの修正版と比べる確認スクリプト

Linux・macOS・WSL・Git Bashで動くように書いたシェルスクリプトです。系列ごとの修正版と比べ、古ければ終了コード1を返すので、CIのジョブの先頭にも置けます。

#!/usr/bin/env bash
# git --version の例: "git version 2.56.1" "git version 2.56.1.windows.1"
v=$(git --version | awk '{print $3}' | cut -d. -f1-3)
series=$(echo "$v" | cut -d. -f1-2)

case "$series" in
  2.56) fixed=2.56.1 ;;
  2.55) fixed=2.55.1 ;;
  2.54) fixed=2.54.1 ;;
  2.53) fixed=2.53.1 ;;
  2.52) fixed=2.52.1 ;;
  2.51) fixed=2.51.3 ;;
  2.50) fixed=2.50.2 ;;
  *)    echo "git $v: 修正版の無い系列。配布元の修正状況を確認"; exit 1 ;;
esac

# sort -V で小さい方が先頭に来る。先頭が修正版なら現在の版はそれ以上
if [ "$(printf '%s\n' "$fixed" "$v" | sort -V | head -n 1)" = "$fixed" ]; then
  echo "git $v: OK（$fixed 以上）"
else
  echo "git $v: 要更新（$fixed 未満）"; exit 1
fi

どのGitが呼ばれているかはcommand -v git（PowerShellならGet-Command git）で確かめます。Debianのように配布元が修正を戻すパッケージでは、このスクリプトは誤って「要更新」と出すので、dpkg -l gitの版番号をセキュリティトラッカーの修正版と照らします。上のスクリプトは公式の版番号をもとに書いたもので、私たちは未実行です。

Git for Windows・GitHub Desktop等の同梱Gitの版確認

GitHub公式ブログは、Gitを同梱するアプリも更新が必要だとしています。2026年11月10日時点で、GitHub DesktopとGitHub Copilot appは修正済みのGitを含むリリースを調整中、GitHub CodespacesとGitHub Actionsは修正済みのGitを提供予定と書かれています。

同梱アプリは、システムに入れたGitを上げても中のGitは古いままです。アプリの設定画面や更新履歴で同梱Gitの版を見るか、アプリ自体を更新します。GitHub Actionsのホストランナーは、提供されるまでジョブのログに出るgit --versionで確かめます。

GitLab・GitHub Enterprise Serverのサーバー側修正版

リポジトリ管理サーバーは、OSのGitではなく製品が持つGitが動いています。GitLabは、16.2以降のCE・EEで19.3.8・19.4.6・19.5.4より前の版が対象です。公式のLinuxパッケージとコンテナイメージは修正済みのGitを含みますが、ソースから入れた環境はGitalyのGitを再ビルドします。手順と、同時に出たKEV掲載の脆弱性の扱いはGitLab脆弱性の対応手順と修正版19.5.4・19.4.6にまとめています。

GitHub Enterprise Serverは、3.19.15・3.20.11・3.21.9・3.22.4で修正済みのGitが入りました。github.comとGitHub Enterprise Cloudは、GitHub側で修正済みです。

信頼できないリポジトリを再帰クローンしない運用：手元とCIの設定例

GitHub公式ブログは、更新できない場合の回避策として、信頼できるサーバーからだけクローンすること、信頼できないリポジトリを再帰クローンしないこと、信頼できない内容やタグをマージしないことを挙げています。同時に、回避策は更新の代わりにならないとも書いています。

–recurse-submodulesなしの本体取得とシンボリックリンクの事前確認

中身を確かめたいだけの外部リポジトリは、submoduleを取らずに本体だけをクローンします。git-cloneの公式ドキュメントのとおり、--recurse-submodulesを付けなければsubmoduleは取得されません。

# submoduleを取らずに本体だけ取得する
git clone https://example.com/org/repo.git
cd repo

# どんなsubmoduleが登録されているかを先に見る
git config -f .gitmodules --get-regexp '^submodule\..*\.(url|path)$'

# リポジトリに含まれるシンボリックリンク（mode 120000）を一覧する
git ls-tree -r HEAD | awk '$1 == "120000"'

攻撃の材料は親リポジトリ側に入っているため、.gitmodulesのURLが見慣れたものでも安全とは言えません。後からgit submodule update --init --recursiveで取り込む操作が同じ経路を通るかは公表情報に書かれていないので、修正版に上げるまでは再帰クローンと同じ扱いにします。submoduleを含むリポジトリの扱い方はGit Worktreeとsubmodule併用の注意点も参考になります。上のコマンドは公式の記載をもとに書いたもので、私たちは未実行です。

submodule.recurseはcloneに効かないため設定だけで防いだと考えない

git-configの公式ドキュメントによると、submodule.recurseは--recurse-submodulesを既定で有効にする設定で、既定値はfalseです。対象はcheckout・fetch・pull・switchなどで、cloneは対象外と明記されています。

つまり、git config --global submodule.recurse falseを配っても、誰かがgit clone --recurse-submodulesを打てば再帰クローンになります。社内の手順書やREADME、セットアップ用スクリプトに--recurse-submodulesが書かれていないかをgrepで探し、外部のリポジトリに使う箇所から外します。

GitHub Actions・GitLab CIのsubmodule取得無効設定

CIは人の目を通さずに外部のコードを取り込むため、手元の端末より影響が大きくなる環境です。actions/checkoutのsubmodulesは既定でfalseで、recursiveを指定したときに再帰します。GitLab Runnerの設定ではGIT_SUBMODULE_STRATEGYがnone・normal・recursiveの3値を取ります。

# GitHub Actions（.github/workflows/ci.yml の一部）
- uses: actions/checkout@v7
  with:
    submodules: false      # recursive にしない
- run: git --version       # ランナーのGitの版をログに残す

# GitLab CI（.gitlab-ci.yml の一部）
variables:
  GIT_SUBMODULE_STRATEGY: none   # recursive にしない
check_git:
  script:
    - git --version

submoduleがビルドに要るリポジトリは、フォークからのプルリクエストのジョブだけnoneにし、マージ後のジョブで取得する分け方があります。アクションの指定をタグでなくコミットSHAで固定する方法はSHA PinningでGitHub Actionsを固定する方法、ワークフローの基本はGitHub Actionsでビルド・自動テストを設定する方法で扱っています。上の設定は公式の記載をもとに書いたもので、私たちは未実行です。

対応の優先順位と判断：更新を当日に回す環境と運用回避で待てる範囲

順番は「誰が用意したリポジトリを、人の確認なしに取り込むか」で決めます。

外部のリポジトリやフォークのプルリクエストを自動で取り込むCIを最優先

最優先は、フォークからのプルリクエストや、外部のリポジトリをsubmodule付きで取得するCIです。自前で運用するランナー（self-hosted runner）は、GitHubがホストランナーのGitを更新しても自動では直りません。ランナーには秘密情報やデプロイ用の認証情報が置かれていることが多く、コードが動けばそこまで届きます。

次がGitLabやGitHub Enterprise Serverのようにサーバー側でマージを実行する製品、その次が開発者のPCです。更新を定期作業として回す仕組みづくりはパッチ管理の手順を参考にしてください。

社内の信頼できるリポジトリだけを扱う端末で更新を次の定期作業に回す条件

私たちの判断は次のとおりです。社内のリポジトリだけを扱い、submoduleも社内のものだけで、外部のリポジトリをクローンする業務が無い端末は、当日でなく次の定期更新に回してかまいません。CVE-2026-111760はCVSSの評価で「攻撃の難しさが高い」「利用者の操作が要る」とされており、細工したリポジトリを取り込ませる経路が無ければ成立しません。

見送ってはいけないのは、OSSの検証や受託案件で外部のリポジトリを日常的にクローンする端末と、CIのランナーです。社内のリポジトリでも、外部の依存先をsubmoduleとして取り込んでいるなら、その依存先が乗っ取られた時点で同じ立場になります。依存先を含めた守り方はソフトウェアサプライチェーンセキュリティの実装判断で整理しています。

Gitの脆弱性CVE-2026-111760ほか6件の対応でよく受ける質問と回答

版の確認と更新の作業中に出やすい疑問に、2026年11月14日時点の一次情報の範囲で答えます。

2.56系に上げられない場合は何を入れればよいですか？

使っている系列の修正版を入れます。2.55系なら2.55.1、2.51系なら2.51.3、2.50系なら2.50.2です。2.56.1のリリースノートとGitHub公式ブログは、これらの系列にも同じ修正を戻したと書いています。2.49以前の系列にはGitプロジェクトの修正版が無いため、配布元の修正パッケージを待つか、2.50系以降へ移ります。

submoduleを使っていないリポジトリでも更新は必要ですか？

必要です。CVE-2026-111760は再帰クローンのときだけですが、残りの5件はsubmoduleと関係なく起きます。空のリポジトリのクローン（CVE-2026-113408）、署名の多いタグのマージ（CVE-2026-114467）、バイナリパッチの適用（CVE-2026-114469）、大量コンフリクトのマージ（CVE-2026-105437）がきっかけになります。どれも日常の操作の範囲です。

Visual Studio CodeなどのエディタのGit連携も対象ですか？

エディタのGit連携の多くは、システムに入っているGitを呼び出して動きます。その場合の対処は、システムに入っているGitを修正版へ更新することです。エディタやGUIクライアントがGitを同梱している場合は、そのアプリの更新が要ります。どちらかは、エディタの設定にあるGitのパスか、出力ログに表示される版で判断できます。

実際に悪用されているかはどこで確かめられますか？

2026年11月14日時点で、GitHub公式ブログとGHSAに悪用を確認したという記載はありません。悪用の有無は米CISAのKEVカタログと、GHSAの更新で追います。CI経由ならリポジトリ1つを取り込ませるだけで成立する経路なので、悪用の報告を待たずに更新を進めてください。

脆弱性スキャナーが2.56.1でも未修正と表示するのはなぜですか？

GHSA-vp2w-7xxj-jvxrの修正版の欄が、2026年11月14日時点でnoneのままだからと考えられます。スキャナーがこの欄を元に判定していると、修正版に上げても検出が続きます。2.56.1のリリースノートとGitHub公式ブログで修正済みを確かめたうえで、スキャナー側で例外として扱い、GHSAの欄が更新されたら例外を外してください。

関連記事

• Gitの最新バージョンは2.56.0｜確認・アップデート方法とGit 3.0の変更点：OSごとにGitを修正版へ上げる手順と、配布元ごとに届く版の違いです。
• Git for Windowsの最新版は2.56.0｜ダウンロード・インストール手順と更新方法：Windows端末をまとめて更新するときのサイレントインストールまで扱っています。
• GitLab脆弱性の対応手順：CVE-2026-105437の修正版19.5.4／19.4.6とKEV掲載CVE-2026-97229の判断基準：Gitaly側で同じCVE-2026-105437を直すGitLabサーバーの手順です。
• Git Worktree（ワークツリー）とは｜使い方・削除(remove/prune)とsubmodule併用の注意点：submoduleを含むリポジトリの扱い方です。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：開発基盤の点検を外部に頼むときの判断材料です。