Michael JohnsonターミナルのGitを更新しても、作業は終わりではありません。個別のアプリやビルド環境が独自のコピーを実行していることがあります。2026年11月10日、Gitプロジェクトは、再帰的クローン時のコード実行からマージ時のメモリ破損まで、6つの脆弱性に対する修正を公開しました。シェルでgit --versionを実行した結果だけでなく、リポジトリやその内容を扱うすべての環境を確認する必要があります。
アップデートで何が変わったか
修正はGit 2.56.1に含まれ、サポート対象の各系列にもバックポートされました。対象は2.55.1、2.54.1、2.53.1、2.52.1、2.51.3、2.50.2です。パス、リンク、署名、バイナリパッチ、マージ、インポートストリームを扱うGitの複数箇所で、6つの問題が修正されています。GitHubは11月10日に脆弱性の解説と更新の推奨を公開し、Git 2.56.1のリリースノートには、このリリース系列で修正されたCVEが列挙されています。
実務上は、3か所で使われるGitを更新する必要があります。開発者のコンピューター、自動化環境、そしてGitを独自にビルドして同梱するアプリです。最後の点は見落としやすく、システムパッケージを更新しても、各クライアントやビルドイメージ内のバージョンが自動的に変わるわけではありません。
再帰的cloneに注意すべき理由
最も分かりやすい攻撃経路は、信頼できないリポジトリを再帰的にクローンする場合です。パスの長さが切り詰められるため、非常に長いパス表記がある名前で検査を通過し、その後、短縮された名前でディスクに書き込まれる可能性がありました。Gitで説明されているシナリオでは、これを利用してサブモジュールの.gitファイルを、悪意ある設定やフックを含むディレクトリへのシンボリックリンクに置き換えることができました。その後Gitがアクセスすると、攻撃者が指定したコードを実行する可能性があります。
実務上重要なのは、細工されたリポジトリと特定の操作が必要だという点です。外部のプロジェクトを--recurse-submodules付きで頻繁にクローンするチームは、クライアントと自動化環境を優先して更新してください。修正により、パスの長さが切り詰められる前に、長すぎるパスが拒否されます。
Gitが信頼できないデータを扱うその他の場面
別の問題は、Git protocol v2で空のリポジトリをクローンするときに発生します。サーバーが、ディレクトリをさかのぼる要素を含むブランチ名を持つHEAD参照を送信する可能性がありました。その後のブランチ更新処理で、想定される参照ディレクトリの外にファイルを書き込める場合がありました。修正済みバージョンでは、Gitはこのような書き込み先や、プロトコル経由で受け取るその他の参照名を検証します。
マージやパッチ操作にも、個別の脆弱性がありました。署名を処理する際、固定長配列は最大2つの署名しか想定していませんでした。署名を多数含むよう細工されたメッセージによって配列の範囲外への書き込みが発生し、メモリが破損するおそれがありました。バイナリパッチの適用では、圧縮前の表現を基準にサイズを検証していましたが、圧縮データは解凍後に大幅に大きくなることがあります。現在のGitは、処理前に申告された非圧縮サイズを検証します。
大規模なマージでも、必要なバッファーの計算時にオーバーフローが発生し、その後、領域の範囲外に書き込む可能性がありました。信頼できない内容をマージするホスティングサービスやアプリケーションも影響を受けます。さらに、git fast-importの3つの機能に、入力ストリーム内のコマンドに対する制限が導入されました。rewrite-submodules-fromとrewrite-submodules-toは任意のファイルを読み取る可能性があり、export-pack-edgesはファイルを作成したり、既存ファイルにデータを追記したりする可能性がありました。これらの機能は、明示的に--allow-unsafe-featuresフラグを指定しない限り無効になります。このフラグは、信頼できるストリーム生成ツールでのみ使用してください。
Gitの個別コピーを探す場所
開発者は、まずGitの実行元を洗い出しましょう。ターミナルでバージョンを確認し、IDEやデスクトップGitクライアントの標準の更新確認機能を使います。次に、cloneやmerge、バイナリパッチの適用、fast-importの実行を行うCIイメージ、コンテナー、runner、サーバージョブを確認してください。ホストに新しいGitが存在していても、アプリケーションがそれを使っているとは限りません。
組織では、元のイメージだけでなく、すでに展開済みの環境も確認するとよいでしょう。常駐runnerや社内サービスは、ベースイメージを更新しても古いバイナリを保持していることがあります。GitHubは、GitHub Enterprise Serverの修正済みバージョンとして3.19.15、3.20.11、3.21.9、3.22.4を案内しています。同社によると、github.comとGitHub Enterprise Cloud（データ所在地オプションを含む）にはすでに修正を展開済みです。GitHub DesktopとGitHub Copilot app向けに修正済みGitを含むリリースは調整中で、CodespacesとGitHub Actions向けの修正版も今後提供される予定です。
更新までのリスクを下げる方法
すぐに修正を適用できない場合は、信頼できないデータを扱う操作を一時的に制限してください。信頼できるサーバーからのみリポジトリをクローンし、未検証のプロジェクトの再帰的クローンを避け、その内容をマージしないようにします。また、そこから取得したバイナリパッチやfast-importストリームも適用しないでください。こうした対策は特定の脆弱な状況への接触を減らしますが、更新の代わりにはなりません。
実務上の結論は明快です。Gitの修正が必要なのは、プログラムが実際にGitを実行する場所です。ターミナルのコマンドはそのうちの一つにすぎず、開発クライアント、CI、リポジトリ処理サービスも個別に確認する必要があります。
