Git 2.56.1が公開、再帰クローンでコード実行のおそれなど6件を修正。サブモジュールの.gitをすり替える欠陥

まず初めに

cloneは、開発者が世界に対して最も無防備になる瞬間の1つだ。他人のリポジトリを、ろくに中身も見ずに手元へ引き寄せ、サブモジュールごと全部持ってくる。その「全部持ってくる」の途中で、.gitそのものがすり替わる。信頼の入口に仕掛けられた欠陥ほど、性質の悪いものはない

※個人の感想です

公式発表の内容

GitHubは2026年11月10日、公式ブログでGitのセキュリティ脆弱性への対処を発表しました。Gitプロジェクトは、悪意のあるリポジトリの再帰クローン時における任意コード実行、意図しないファイルへの書き込み、マージやバイナリパッチ処理時のメモリ破壊を含む、6件の脆弱性に対処する新バージョンを公開したという内容です。

修正はGit 2.56.1に含まれます。あわせて、旧系列向けのバックポートとして2.55.1、2.54.1、2.53.1、2.52.1、2.51.3、2.50.2が公開されました。同社は、2.56.1または使用中のメンテナンス系列のパッチ適用版への更新と、Gitを同梱するアプリケーションの更新を推奨しています。

中核の欠陥CVE-2026-111760

中心となるCVE-2026-111760は、再帰クローン時のコード実行です。Gitはファイルをワーキングツリーへ書き出す前にパスを検査し、自らのリポジトリメタデータを上書きするようなパスを拒否します。しかし公式発表によると、Gitのインデックス処理における整数の切り詰めにより、極端に長いパスが、ある名前では検証を通過し、実際にはより短い名前で書き込まれるという食い違いが生じ得ました。

攻撃者はこの食い違いを利用して、サブモジュールの.gitファイルを、悪意のある設定やフックを含むディレクトリを指すシンボリックリンクに置き換えることができます。Gitがその後そのディレクトリを使う際に、再帰クローンの過程で攻撃者が用意したコードが実行され得る、というのが欠陥の構図です。修正では、極端に長いインデックスエントリのパスを、切り詰めが起きる前に拒否するようになりました。

残る5件

公式発表とoss-securityへの転載では、このほかに5件が列挙されています。サーバーから通知されるHEAD参照を経由したパストラバーサル（CVE-2026-113408）、3件を超えるGPG署名の処理におけるスタック破壊（CVE-2026-114467）、バイナリパッチ展開時の境界外読み取り（CVE-2026-114469）、大規模なマージ処理におけるヒープ破壊（CVE-2026-105437）、fast-importを経由したファイルアクセス（CVE-2026-114466）です。

いずれも、信頼できないリポジトリやデータを処理する場面で到達し得る種類の問題です。GitHubのホスト型サービス側については、同社の発表の時点で対応が進められている旨が案内されていますが、各自の手元やCI環境で動くGit本体は、利用者側の更新がなければ直りません。

開発現場向けの点検

点検の順序はシンプルです。まず、手元とCIの双方でgit --versionを確認し、2.56.1または各系列のパッチ版（2.55.1、2.54.1、2.53.1、2.52.1、2.51.3、2.50.2）以降になっているかを調べます。次に、IDEやGUIクライアント、デプロイツールなど、Gitを同梱して配布しているアプリケーションが古いGitを抱えていないかを確認します。同梱版はOSのパッケージ更新では直らないため、見落とされやすい箇所です。

運用面では、出所の分からないリポジトリを--recurse-submodules付きで安易にクローンしないことが、当面のリスク低減になります。サブモジュールを含む外部リポジトリを取り込む作業は、更新が済んだ環境で行うのが安全です。言語ランタイムの更新が相次ぐ週ですが、Rust 1.100.0（Rustの記事）が新機能のリリースだったのに対し、こちらは全開発者が対象のセキュリティ修正です。

バージョン系列の整理

修正版の対応関係を整理すると、最新系列が2.56.1、1つ前の系列が2.55.1、以下2.54.1、2.53.1、2.52.1、2.51.3、2.50.2と、各メンテナンス系列に1つずつパッチ版が用意されています。自分がどの系列にいるかを確認し、系列を飛ばして最新へ上げるか、系列内のパッチ版へ上げるかは、各現場の検証体制に合わせて選べます。どちらを選ぶにせよ、脆弱な版のままにしないことが要点です。

コンテナイメージやCIランナーのベースイメージにGitが含まれている場合、そのイメージの再ビルドや差し替えも更新の一部です。手元の開発機だけを直して、CI側の古いGitで外部リポジトリをクローンし続ける構成は、境界の片側だけを閉じた状態になります。棚卸しの対象には、ランナー、ビルド用コンテナ、デプロイ先サーバーの3か所を含めてください。

IT Postの見方

IT Postでは、この件の本質は「cloneという日常動作が、信頼の境界を越える操作だ」という再確認だと考えます。コードを実行する前にコードを取り込む。その取り込み自体が実行の引き金になり得る欠陥は、サプライチェーンの議論で繰り返し指摘されてきた構図そのものです。

実務上の優先順位は高くてよいはずです。Gitはほぼ全ての開発現場にあり、更新の手間も小さい。バックポートが6系列分も用意されたのは、プロジェクト側がそれだけ広く行き渡らせる必要があると判断した証拠です。同梱Gitの棚卸しまで含めて、週内に片付ける類いの作業です。

今後どうなりそうか

今後は、各OSディストリビューションやパッケージマネージャー、IDE同梱分への修正の行き渡りが焦点になります。発表時点で実環境での悪用の公表は一次資料にありませんが、修正が公開された以上、未更新環境のリスクは時間とともに上がります。

新たな事実が公表されれば、本記事を更新します。