GitSpawnが突いたAIコーディングエージェントとgit設定の信頼境界

受け取ったzipを展開し、そのフォルダでAIコーディングエージェントを起動する。この操作だけで、リポジトリ側が指定したコマンドが利用者の権限で走ってしまう脆弱性クラスが、2026年9月1日にManifold Securityから「GitSpawn」の名前で公開されました。プロンプトを一文字も入力していない段階で、承認ダイアログもワークスペースの信頼確認も通らないまま実行される点が、この問題の性質を決めています。

この記事は、gitの設定値がコマンド実行のシンクになる機構、影響を受けた製品と修正状況、そして開発者と情報システム担当が取れる防御策を整理します。記述はManifold Securityの公開記事、NVDに登録されたCVE、各ベンダーの公式アドバイザリと変更履歴、Gitの公式ドキュメントで確認できた範囲に限り、確認できなかった事項は書きません。

まず、この脆弱性クラスの輪郭を一覧にします。

gitの設定値がコマンドとして実行される仕組み#

gitは性能向上や表示の差し替えのために、外部プログラムを呼び出す設定を多数持っています。そのうちのいくつかは、設定値そのものが実行されるコマンドの文字列です。

代表がcore.fsmonitorです。Gitの公式ドキュメントは、この変数が真偽値でない場合について「Otherwise, this variable contains the pathname of the "fsmonitor" hook command.」と説明し、このフックコマンドが、要求された時刻以降に変更された可能性のあるファイルを特定するために使われると記しています。gitはワーキングツリー全体をlstatで舐める代わりに、この外部プログラムに変更ファイルの一覧を尋ねます。呼び出しはインデックスを更新するあらゆる操作で発生するため、git statusとgit diffが引き金になります。

もう一段の前提が、設定の読み込み順です。git-configのドキュメントは、システム全体の設定、利用者ごとのグローバル設定、リポジトリローカルの$GIT_DIR/config、ワークツリー設定、そして環境変数とコマンドラインの-cという順で読み、後から読んだ値が勝つと定めています。つまりリポジトリ自身が置いた.git/configは、利用者のグローバル設定より強い立場にあります。

ここまではgitの正常な仕様です。GitSpawnが指摘したのは、この仕様とAIコーディングエージェントの起動処理が噛み合ったときに生じるずれでした。エージェントは起動直後、いまどのブランチにいて何が変更されているかをシステムプロンプトに載せるために、自前の子プロセスとしてgitを走らせます。この呼び出しでリポジトリ側の設定を取り除いていなければ、リポジトリが指名したプログラムが、利用者の権限で、承認を求められることなく起動します。Manifold Securityの記事はこの構図を「The repository names a command, git runs it, on the host, with the user's privileges, before any approval prompt.」と表現しています。

エージェント側にサンドボックスがあっても効きません。サンドボックスはモデルが要求したツール実行を包む仕組みであり、文脈収集のためにエージェント自身が呼ぶgitは、その枠の外側で動くためです。CVE-2026-19592のNVD記述も、実行されるヘルパについて「The helper runs outside Codex's command sandbox and without a user-approval prompt」と明記しています。

あわせて読みたい

プロンプトインジェクションとは。AIエージェント時代の新しい攻撃と防御

一次情報で確認できたコマンド実行シンク#

Manifold Securityは記事の中で、未修正の製品が残っている段階では悪用可能な設定キーをすべて名指ししない方針を取り、core.fsmonitorだけを具体名で示しています。一方で、OpenAIがCNAとして採番したCVEの記述には、別のキーが明示されています。以下は一次情報で確認できた分です。

core.hooksPathについて、Gitのドキュメントはフックの探索先を$GIT_DIR/hooksから任意のパスへ差し替える設定だと説明しています。リポジトリがこの値を書き換えれば、.git/hooksの中身を直接見ても気づけない場所にフックを置けます。CVE-2026-19590はCodex Desktopがこの設定を信頼していた件で、CVSS v3.1の基本値は7.3です。

attr.treeは、ワーキングツリーの.gitattributesの代わりに、リポジトリ内のツリーオブジェクトから属性を読む設定です。属性で有効化されるfilter.<driver>.cleanは、ドキュメントが「The command which is used to convert the content of a worktree file to a blob upon checkin.」と説明するとおり、これも値がコマンドです。CVE-2026-19593はこの組み合わせを扱っており、CVSS v3.1の基本値は9.8と、公表済みのGitSpawn関連CVEの中で最も高い値が付いています。

Cursorは自社のCLI変更履歴の2026年8月11日の項に「Hardened git commands. Repository-controlled git configuration, including fsmonitor, hooks, attributes, and external diff programs, no longer runs during the agent's own git operations.」と記載しました。ベンダー自身が、無効化した対象を4系統として公表している点が参考になります。

なお、Manifold Securityが2026年7月15日に報告したClaude Codeの2件目については、記事本文が「It is a different git setting of the same kind, one the review path does not strip.」とだけ述べ、キー名を伏せています。執筆時点で該当キーを一次情報から特定することはできません。

影響を受けた製品と修正状況#

Manifold Securityは、7製品にまたがる8件の指摘として公開しました。以下は、同社の記事と各CVEの登録内容から確認できた範囲です。バージョン番号と状態は、同社が2026年9月1日に再検証した時点のものです。

gooseの件は、脆弱な処理まで公表されている点で読み解きやすい事例です。GitHub Security Advisory GHSA-r5pp-p5r8-466rとNVDの記述によれば、goose reviewが差分を集めるために呼ぶgitは、crates/goose-cli/src/commands/review/handler.rsのgit_command()で組み立てられ、付いていたのは-c core.quotePath=offだけでした。core.fsmonitorは残ったままで、git diff HEADのインデックス更新時に実行されます。アドバイザリは、この実行がモデルへの接続より前に起き、プロンプトの送信もツール承認も信頼確認も介在しないと述べています。CVSS v4.0の基本値は7.0です。

Hermes Agentは、VulnCheckがCVE-2026-71963を採番しました。NVDに登録された記述では、影響範囲は0.18.2から0.21.0、修正はコミットf6234d0で、利用者が悪意あるリポジトリを開いて何らかのメッセージを送るとgit statusのインデックス更新が走り、注入されたコマンドが利用者のプロセス文脈で実行されて、設定済みのプロバイダAPIキーを含む環境全体が露出するとされています。CVSS v4.0で8.6、CVSS v3.1で8.8です。

未修正と記載した3製品については、Manifold Securityが9月1日に再検証した結果に基づく執筆時点の報道ベースの情報です。各ベンダーがその後に修正を出している可能性があるため、実際の判断は各製品の公式リリースノートで確認してください。

clone では成立しない配送経路#

この脆弱性クラスの成立条件で見落とされやすいのが、リポジトリの届き方です。git cloneは複製元の.git/configをそのまま持ってきません。git-cloneのドキュメントが説明する初期設定は、リモート追跡ブランチの作成とremote.origin.urlおよびremote.origin.fetchの初期化であり、複製元のローカル設定の写しではありません。

この点はCVEの記述にも明記されています。CVE-2026-19593は「An ordinary Git clone does not copy the source repository's .git/config and is not sufficient by itself.」と述べ、CVE-2026-19592も同趣旨の文を含んでいます。

したがって、攻撃が成立するのは.gitディレクトリごとファイルとして届く経路です。具体的には、zipやtarのアーカイブ、共有ドライブやファイルサーバに置かれたフォルダ、クラウド同期フォルダ、USBメモリ、そしてコンテナイメージやバックアップからの復元が該当します。「面接課題です」「再現手順つきのバグ報告です」といった名目でアーカイブが届く流れは、日常業務の中にすでにあります。

配送経路が限られることは、悪用のハードルを上げる一方で、検知の手がかりにもなります。社内に届くアーカイブの取り扱いを整理するときは、.gitを含む展開物を通常のコードレビューと同じ扱いにせず、隔離環境で開く運用に寄せる判断がしやすくなります。

あわせて読みたい

サプライチェーン攻撃の構造と防御の考え方。ソフト・ハード・サービス経由の侵入をどう減らすか

手元での確認手順#

自分の環境で挙動を確かめる場合は、自分が所有する使い捨てのディレクトリで行います。以下は無害なマーカーを書き出すだけの確認です。

# 使い捨てディレクトリでの確認例
git config --get core.fsmonitor            # 開こうとしているリポジトリの設定を見る
git config --list --show-origin | grep -E 'fsmonitor|hooksPath|attr\.tree|filter\.|diff\.external|sshCommand'

この確認で押さえておきたいのが、対策として広く紹介されているgit config --global core.fsmonitor falseの効き目です。git 2.52.0で試したところ、グローバル設定にfalseを置いてもリポジトリローカルの値が優先され、コマンドは実行されました。git config --show-origin --get core.fsmonitorの出力もfile:.git/configを指しました。設定の読み込み順から見れば当然の結果です。

一方で、コマンドラインの-cと、GIT_CONFIG_COUNTおよびGIT_CONFIG_KEY_<n>とGIT_CONFIG_VALUE_<n>による上書きは、いずれもファイル由来の設定より優先されるため実行を止められました。エージェント側の修正がgit -c core.fsmonitor=false statusの形を取っているのも同じ理屈です。OpenAIのcodexリポジトリで公開されているPull Request #22652は、タイトルが「[codex] Ignore fsmonitor config in Git metadata reads」で、メタデータ取得のgit呼び出しをリポジトリのcore.fsmonitor設定から切り離す変更です。

# エージェントを起動するシェルにだけ、上書きを効かせる例
GIT_CONFIG_COUNT=1 \
GIT_CONFIG_KEY_0=core.fsmonitor GIT_CONFIG_VALUE_0=false \
  <エージェントの起動コマンド>

この上書きは万能ではありません。止まるのは指定したキーだけで、core.hooksPathやattr.treeなど他のシンクは別に指定する必要があります。設定キーの数は多く、gitの版が上がれば増える可能性もあるため、この方法は隔離が用意できるまでのつなぎとして位置づけるのが妥当です。

Git 本体の保護が届く範囲と届かない範囲#

gitにも、リポジトリの設定を無条件に信じないための仕組みがあります。ただし、GitSpawnが想定する場面では効きません。

safe.directoryは、他人が所有するリポジトリの設定を読まないための仕組みです。git-configのドキュメントは「By default, Git will refuse to even parse a Git config of a repository owned by someone else, let alone run its hooks」と説明しています。ところが、自分でzipを展開して作ったディレクトリは自分の所有物です。所有者が一致するため、この検査は通過します。

もう1つが保護された設定スコープです。ドキュメントは「Protected configuration refers to the system, global, and command scopes. For security reasons, certain options are only respected when they are specified in protected configuration, and ignored otherwise.」と述べ、safe.directoryやsafe.bareRepositoryがこれに当たると記しています。この扱いは、リポジトリ側が安全装置そのものを書き換えるのを防ぐためのものです。core.fsmonitorやcore.hooksPathは性能や運用のための設定であり、この保護対象には含まれていません。

つまりGitの側から見ると、リポジトリローカル設定が外部コマンドを指名できることは仕様どおりの挙動です。境界を引く責任は、そのリポジトリを開くツールの側にあります。

この責任分担は新しい話ではありません。Visual Studio Codeは、公式ドキュメントが「The Workspace Trust feature lets you decide whether code in your project folder can be executed by VS Code and extensions without your explicit approval.」と説明するWorkspace Trustを1.57で導入し、信頼していないフォルダを制限モードで開く設計を取りました。フォルダを開いた時点で何が動きうるかという問題は、エディタの世界で先に整理されていたことになります。AIコーディングエージェントは、その整理をもう一度たどり直している段階にあると読めます。

開発者と情報システム担当の防御策#

対策は、リポジトリの信頼度で経路を分けるところから始めます。

信頼できないリポジトリについては、cloneしただけの状態、あるいは展開しただけの状態でエージェントを起動しないという線引きが最初の一手です。エージェントを起動する前に.git/configを開いて中身を読み、外部プログラムを指名する設定が入っていないかを確かめます。Manifold Securityの記事も、受け取り側への助言として「Inspect .git/config before you open the directory with an agent. Any setting that names a program can run it.」と書いています。

次が隔離です。コンテナやdevcontainer、あるいは専用の低権限ユーザで作業すれば、仮にコマンドが走っても届く範囲を絞れます。Claude Codeの公式ドキュメントは、dev containerについて「While the dev container provides substantial protections, no system is completely immune to all attacks.」と限界を明記したうえで、~/.sshやクラウド資格情報のようなホスト側の秘密をコンテナへマウントせず、リポジトリスコープの短命なトークンを使うことを勧めています。同ドキュメントには外向き通信を制限するファイアウォールスクリプトの例も含まれています。隔離を敷くときは、この2点、つまり資格情報をマウントしないことと外向き通信を絞ることを合わせて実施すると効果が出ます。

あわせて読みたい

コンテナ(Docker)セキュリティの基礎と実務で効く守り方

エージェント自体のバージョン管理も欠かせません。修正がバージョン番号で示されている以上、古い版を固定したまま使い続けると、公開済みの手口がそのまま通ります。組織で配布する場合は、更新方針を決めたうえで、利用中の版を棚卸しできる状態にしておきます。

秘密情報の置き方も効きます。実行されたコマンドが持ち出すのは、その利用者の環境で読めるものです。長命のAPIキーを環境変数やホームディレクトリの平文ファイルに置いている状態は、被害の上限をそのまま押し上げます。

あわせて読みたい

シークレット管理の実務。APIキー・認証情報をハードコードせず、Vaultやマネージドサービスで守りローテーションする

検知の面では、gitの子プロセスから見慣れないプロセスが生まれる動きが手がかりになります。git statusやgit diffの配下で、シェルやスクリプトインタプリタ、curlやwgetのような通信手段が起動する系統は、通常の開発作業ではまず現れません。EDRを運用しているなら、親プロセスがgitである子プロセスの生成を可視化し、そこから外向き通信が出る組み合わせを重点的に見ます。

CI/CD と組織的な統制#

エージェントを自動化に組み込んでいる場合は、入力の出どころが問題になります。外部からのプルリクエストをエージェントに読ませる構成では、攻撃者が中身を選べるためです。

GitHubの公式ドキュメントは、pull_request_targetが基点リポジトリのGITHUB_TOKENとシークレットを伴って動く点を挙げ、信頼できないプルリクエストの内容と組み合わせる構成に注意を促しています。同社は2026年6月18日の変更履歴で、pull_request_target使用時にフォーク側のヘッドコミットとマージコミットのチェックアウトを既定で遮断する変更も公表しました。エージェントを呼ぶワークフローも同じ整理が要ります。信頼できない差分を読ませる処理は、シークレットを持たないジョブに分け、書き込み権限を与えないという分離です。

組織全体の方針としては、公的機関の資料が枠組みを提供しています。CISA、NSA、ASD's ACSC、カナダのCyber Centre、NCSC-NZ、NCSC-UKが2026年5月1日に共同公開した「Careful Adoption of Agentic AI Services」は、エージェント型AIの導入にともなうリスクと、設計から運用までの実践事項を整理しています。国内では、IPAが2026年1月29日に公表した「情報セキュリティ10大脅威 2026」の組織向け第3位に「AIの利用をめぐるサイバーリスク」が初選出されました。IPAの「AIセキュリティ短信」も、AIコーディングエージェントの承認迂回やサンドボックス脱出の事例を継続的に取り上げています。

あわせて読みたい

DevSecOps入門。CI/CDにセキュリティを組み込むSAST・DAST・SCA・シークレットスキャン

Manifold Securityは2026年9月1日にGitSpawnを公開し、7製品にまたがる8件の指摘と、各ベンダーへの報告日および対応状況を一覧で示しています。同社は、未修正の製品が残る間は悪用可能な設定キーをすべて名指ししない方針を取り、記事中で具体名を挙げているのはcore.fsmonitorのみです。受け取り側への助言としてはエージェント起動前の.git/config確認を、ベンダー側への助言としては文脈収集のgit呼び出しでの設定除去(例としてgit -c core.fsmonitor=false status)を挙げています。

押さえておきたい前提と限界#

この記事で扱った内容には、いくつか範囲の限定があります。

未修正と記した製品の状態は、Manifold Securityが2026年9月1日に再検証した時点の情報です。修正が出ているかどうかは、各製品の公式リリースノートで都度確認してください。Claude Codeのcore.fsmonitor経路については、修正版として2.1.196が挙げられていますが、ベンダーが個別の公開アドバイザリを出していないため、この番号は同社の報告に基づく記載です。

Claude Codeについては、GitSpawnとは別に、gitのworktree処理に起因するCVE-2026-55607が公表されています。NVDの記述では、2.1.38から2.1.163未満が影響し、.gitという名前のworktreeを作れたことによるgitディレクトリの取り違えと、シンボリックリンク操作およびworktree操作時のfsmonitor実行を組み合わせて、.zshenvなどホームディレクトリのファイルを上書きし、macOSのseatbeltサンドボックスの外でコードを実行できたとされています。修正は2.1.163です。同じくgitのfsmonitorが登場しますが、成立経路が異なる別の件として扱われています。

Cursorについても、GitSpawnとは別にCVE-2026-26268が公表されています。プロンプトインジェクションを受けたエージェントが保護の不十分な.git設定に書き込むことで、次に発火したときにサンドボックス外のコード実行につながるという内容で、2.5未満が影響し2.5で修正されています。書き込む主体がリポジトリではなくエージェント側である点が、GitSpawnとの違いです。

実環境での悪用については、執筆時点で確認できた一次情報がありません。CISAのKnown Exploited Vulnerabilities カタログへの登録も、執筆時点では確認できていません。

リポジトリを開くという操作は、これまで読み込みに近い行為として扱われてきました。GitSpawnが示したのは、エージェントが文脈を集めるようになったことで、その操作が実行を伴うものへ変わっていたという事実です。境界をどこに引き直すかは、ツール側の修正を待つだけでなく、リポジトリの受け取り方と作業環境の隔離という運用側でも決められます。

あわせて読みたい

MCPサーバーのセキュリティ。AIエージェントとツール接続の信頼境界