Git プロジェクトは 11 月 10 日に一連のメンテナンスバージョンを公開し、6 件の脆弱性をまとめて修正しました。最も深刻なのは CVE-2026-111760 で、攻撃者が管理するリポジトリを git clone --recurse-submodules でクローンすると、自分のマシン上で攻撃者のコードが実行されるおそれがあります。GitHub のアドバイザリはこれを 8.0(high、高)と評価しています。Git プロジェクトは、2.27.0 以降のすべてのバージョンが影響を受けるとしています。修正済みバージョンは 2.50.2、2.51.3、2.52.1、2.53.1、2.54.1、2.55.1、2.56.1 です。2.50 より古いバージョンも影響を受けますが、メンテナンスリリースはもう提供されません。
6 件の脆弱性それぞれが発動する条件
- CVE-2026-111760:Git はファイルパスの長さを 32 ビットのフィールドに格納します。攻撃者は、パスの安全性チェックは通過するものの、ディスクに書き込まれる際には
.gitに切り詰められる、極端に長いパスを作ります。クローンしたばかりのサブモジュールでは.gitはファイルなので、これが悪意のあるディレクトリへのシンボリックリンクに置き換えられ、そこにあるフックや設定が実行されます。発動条件は、攻撃者が管理するリポジトリの再帰的なクローンです。 - CVE-2026-113408:悪意のあるサーバーがプロトコル v2 を使って HEAD を
../を含む名前に向けさせ、その後にgit commitを実行すると、Git が参照ディレクトリの外にあるファイルへ書き込みます。 - CVE-2026-114467:タグのメッセージに 2 つを超える GPG 署名が含まれていると、
git mergeがスタックメモリを破壊し、サービス拒否を引き起こすおそれがあります。 - CVE-2026-114469:展開すると 1 GiB を大きく超えるバイナリパッチがサイズチェックをすり抜け、
git applyが範囲外を読み取ってクラッシュします。 - CVE-2026-105437:3 方向マージのコードにあるヒープオーバーフローで、巨大な
conflict-marker-sizeを.gitattributesに指定し、そこに多数のコンフリクトが重なると発動します。merge、rebase、cherry-pick、merge-tree はいずれもこのコードを通ります。 - CVE-2026-114466:
git fast-importのいくつかの機能で、任意のファイルを読み書きできました。これらは既定で無効になり、本当に使う場合は--allow-unsafe-featuresが必要です。これは後方互換性のない変更です。
サーバーでなぜ問題になるのか
- デプロイスクリプトと CI:再帰的にクローンするスクリプトは数多くあります。Git プロジェクトによると、こうした悪意のあるリポジトリは主要なホスティングプラットフォームのチェックに引っかかるため、そこへ push するのは容易ではありませんが、攻撃者自身のサーバーに置くことはでき、それを指す一見無害な
.gitmodulesがあれば十分です。言い換えれば、リスクは、依存しているサードパーティのリポジトリの中にあるサブモジュールから来ます。 - 自前でホストする Git サービス:ホスティングサービスは、ユーザーに代わってマージが可能かどうかをサーバー側で確認します。発表では、マージ処理のヒープオーバーフローが GitLab ではリモートコード実行にまで発展しうると指摘されています。GitHub によると github.com はすでに修正済みで、GitHub Enterprise Server の修正済みバージョンは 3.19.15、3.20.11、3.21.9、3.22.4 です。
- ディストリビューションのパッケージ:11 月 12 日時点で、Debian 12 の 2.39.5 と Debian 13 の 2.47.3 はまだ vulnerable(脆弱)とされています。古いから安全というわけではありません。アップストリームの示す範囲に従えば、Ubuntu 22.04 に付属する 2.34.1 も影響を受け、ディストリビューションが修正をバックポートするのを待つ必要があります。
今できること
git --version でバージョンを確認し、ディストリビューションの修正済みパッケージが届きしだいアップグレードして、独自に Git を同梱しているアプリケーションも更新してください。パッチを適用するまでの GitHub の助言は、信頼できるサーバーからのみクローンすること、信頼できないリポジトリの再帰的なクローンを避けること、信頼できないコンテンツやタグのマージを避けること、信頼できない提供元のバイナリパッチや fast-import ストリームの処理を避けることです。GitHub は、これらの予防策は修正の適用の代わりにはならないとも述べています。同じ種類のサプライチェーンのリスクはnpm ワームの記事で取り上げました。Git でコードを取得する典型的なデプロイの流れはNode.js アプリのデプロイとDocker 入門にあります。デプロイ用のマシンですでに不明なコードが実行された疑いがある場合は、侵入チェックと強化のガイドに従ってください。