本文へ移動
情シスのミカタ
ニュース約3分で読めます

GitHub、GitPythonのコード実行脆弱性を掲載、例外後もフック残存

GitPythonのcreate_submoduleに、攻撃用のフックを配置できる脆弱性が見つかりました。処理が例外で終わってもファイルが残る検証例があり、外部から受け取るパスと実行環境の確認が必要です。

公開 情シスのミカタ編集部AIにより執筆チェック済み
文字
GitHub、GitPythonのコード実行脆弱性を掲載、例外後もフック残存

この記事のまとめ

  • GitPythonのcreate_submoduleに任意コード実行の脆弱性。識別番号はCVE-2026-114145。
  • 攻撃者が影響するパスと、対象フック名が空いていることが攻撃の条件です。
  • 例外後もフックが残る検証例があります。修正版は資料に記載されていません。
こんな方に#20代#30代#40代#50代#60代実務

GitHubは、GitPythonで意図しないコードを実行される脆弱性「CVE-2026-114145」の情報を掲載しています。外部から受け取ったパスを使う処理では、攻撃用のファイルが配置され、後の操作で実行される恐れがあります。公表日は資料に記載されていません。

パスの検証前にフックが配置される

問題があるのは、サブモジュールを作成するcreate_submoduleのパス検証の順序です。GitHubによると、.git/hooksというパスが、クローン前の検証を通過します。クローンは、リポジトリを複製する処理です。

このため、攻撃用のサブモジュールから実行可能なフックを配置できます。フックは、特定の操作に合わせて動く処理です。配置されたpost-checkoutは、その場ではなく、後のcheckout時に実行されます。

攻撃には、アプリが攻撃者の影響するサブモジュールパスを渡す必要があります。GitHubは、利用者が送るマニフェストやAPI要求からパスを取り込むサービスを、影響する例として挙げています。マニフェストは構成情報などを記したファイル、APIはシステム間で要求をやり取りする窓口です。

さらに、対象のフック名が空いていることも条件です。GitHubは、最小構成の環境や、継続的インテグレーション(CI)、コンテナでのチェックアウトを、攻撃条件に合う例に挙げています。

例外が出ても、配置を防げたとは限らない

GitHubによると、3.1.xでは不正なパスが拒否されず、エラーなしでフックが配置されます。3.2.0以降の検証対象でも、例外が発生する前にフックが書き込まれ、その後も削除されません。

コード実行を確認した対象として、3.1.59と、3.2.0に3コミットを加えたbda18e08が挙げられています。これは検証結果であり、資料には修正版や影響する版の全範囲は記載されていません。3.2.0以降なら安全、と判断できる情報ではありません。

一方、標準のサンプルフックがある場合はクローンが拒否され、フックは配置されないとしています。版だけでなく、パスの取り込み方と実行環境を組み合わせて確認する必要があります。

日本での提供は発表には書かれていません。今回の確認では、社内システムや委託先の処理がGitPythonを使っているかを、まず調べることが出発点になります。

影響する会社・しない会社

  • 影響する: GitPythonのcreate_submoduleに、利用者のマニフェストやAPI要求から得たパスを渡す会社です。攻撃者がパスに影響でき、対象のフック名が空いている場合は、攻撃条件に当てはまります。
  • 影響する: 上記の処理を、最小構成の環境、CI、コンテナで動かす会社です。GitHubが条件に合う例として挙げており、開発者の端末だけの確認では足りません。
  • 影響しない: 攻撃者の影響するパスをcreate_submoduleに渡さない処理は、今回示された攻撃条件に当てはまりません。ただし、製品全体の安全性を示すものではありません。
  • 影響しない: 標準のサンプルフックがあり、説明どおりクローンが拒否される環境では、今回の方法によるフック配置は行われません。この条件だけを恒久対策とみなさず、実環境での確認が必要です。

情シスが今日やること

  1. 開発・運用担当と委託先に利用状況を確認します。 今日の確認依頼では、依存関係の一覧と実行環境を調べてもらい、GitPythonの版、create_submoduleの使用箇所、CIやコンテナでの利用有無を回答項目にします。
  2. パスの入力元を追います。 対象コードで、マニフェストやAPI要求の値がcreate_submoduleに渡るかを確認します。外部から指定できる場合は、次の実行前に開発責任者へ伝え、当該入力を使う処理の一時停止や制限を検討します。
  3. 例外が出た環境も確認対象にします。 運用担当に、対象環境の.git/hooksとpost-checkoutの有無・内容を確認してもらいます。処理が失敗したという記録だけで、安全と判断しないよう共有します。
  4. 更新先を決める前に修正情報を確認します。 GitHubの当該アドバイザリで修正版と対象範囲の追記を確認します。資料には修正版がないため、検証済みの版を更新先と取り違えず、確認結果と暫定対応を開発責任者に報告します。

出典・参考

このニュースは、公式発表と報道をもとに AI を使って作成し、出典と照らして確かめています。まちがいに気づいたら直し、更新日を改めます。

チェック済み。この記事は監修者によってチェックされました。(2026年10月23日)

執筆

情シスのミカタ編集部AIにより執筆

書いた AI: AI記者(ニュース)

企業・官公庁の公式発表を読み、事実を抜き出してから自分の言葉でニュースを書きます。記事には「影響する会社・しない会社」と「情シスが今日やること」を必ず入れます。書いた記事は別のAIが出典と照らして確かめ、通ったものだけを公開します。公式発表を読めない話題は、2つ以上の報道機関が伝えたものだけを「報道から」として書きます。使っているAI: OpenAI GPT-6.1 Sol。

監修

佐々木 航株式会社Game

代表取締役。工学部出身で、21歳で起業してからシステム会社の経営一筋で8期目。アプリの受託開発から始め、いまはAIを使ったシステムソリューションを手がけています。150社以上の企業とのプロジェクトで培った開発と情報システムの現場の経験と声を形にし、激動の時代を乗り越えたいと考えています。

メモ: 掲載時に自動で(しばらくの間)

記事は AI が書き、機械の検査と別の AI の校閲を通してから公開しています。人が見ているもの・見ていないものはAI の使い方に書いています。まちがいに気づいたら訂正・ご指摘からお知らせください。直したら、記事の最後に何を直したかを書きます。

役に立ったら、いいねと共有をお願いします