GitSpawn: 信頼できないリポジトリがAIコーディングエージェント経由でコードを実行可能

GitSpawn: 単一の欠陥により、信頼されていないリポジトリがClaude Code、Codex、Cursor、Grokでコードを実行可能に

更新、2026年9月1日。 OpenAIのCodexとCursorも影響を受けました。両方ともテストおよび報告済みです。それぞれ、別の研究者が既に提出したレポートの重複として扱われ、その後両方ともパッチが適用されました。Codexのバリアントはメカニズムが多少異なりますが、同じクラスに属します。どちらも以下で個別に記述されていません。ケーススタディでは、完全なチェーンを自身で示すことができた場合や、開示記録を文書化する価値がある場合をカバーしています。

TL;DR

• 概要。 AIコーディングエージェントは、コンテキストを収集するためにバックグラウンドでgitコマンドを実行します。一部のエージェントでは、プロンプトを入力する前、ワークスペースの信頼プロンプトの前、さらには認証する前でも実行されます。このコンテキスト収集メカニズムにおける不適切なサニタイズは、AIコーディングエージェント製品全体にわたる広範なセキュリティ脆弱性であり、最終的には任意のコード実行につながります。
• 攻撃者が得られるもの。 開発者と同じ権限で、サンドボックスの外で、承認プロンプトなし、画面上の表示なしで、任意のコードを実行できます。SSHキー、環境内のクラウド認証情報、シェル設定内のトークン、ディスク上のすべてのリポジトリ、そしてマシン上の足がかりを得られます。
• 普及度。 特定のベンダーのバグではありません。Claude Codeは毎月7700万npmダウンロード（npm APIより）を誇ります。5つのプロジェクト全体で、Hermesは237,000以上のGitHubスター、Claude Codeは143,000以上、Gooseは54,000以上、Qwen Codeは27,000以上、Grok Buildは26,000と、合計で50万近くになります。
• 未修正での公開について。 8件の発見のうち4件はまだライブです。すべてプライベートに報告され、公開前に最新リリースで再確認され、ベンダーから承認されるか、返信なしで複数のチャネルで追跡されました。私たちの報告のうち5件は、他の研究者が既に独立して提出した発見の重複として返ってきました。そのうちの1件は私たちのものと同じ日でした。これは複数の方向から発見されています。

7つのエージェントにわたる8件の発見。公開時点で4件は未修正のままです。

Claude Codeでフォルダを開くと、何も入力する前にgit statusが実行されます。ワークスペースの信頼プロンプトの前です。一部のエージェントでは、認証する前でさえです。

そのフォルダがどこか別の場所から来た場合、リポジトリがそのコマンドを実行するものを決定します。

［動画: Ax SharmaとFrancisco RosalesがGit Spawnの発見について議論している様子］

一つの疑問

この研究は一つの疑問から始まりました。CLI AIエージェントが起動時に実際に何をするのか？裏側では何が起こっているのか？

いくつかのAIエージェントを調べた結果、同じ動作を観察しました。それらは、開いたばかりのプロジェクトに関するコンテキストを収集します。その収集の大部分はgitを使用して行われ、さまざまな目的でさまざまなタイミングで呼び出されます。起動時、セッション開始時などです。

gitの使用方法を見ると、脆弱なパターンが見つかりました。これらのコンテキスト収集呼び出しは、リポジトリ自身のgit設定を削除せずに実行され、いくつかのgit設定はコマンド実行のシンク（脆弱な箇所）となります。リポジトリがコマンド名を指定し、gitがそれをホスト上で、ユーザーの権限で、承認プロンプトなしで実行します。

この記事では、Claude Code、Goose、Grok Build、Hermes、Qwen Codeのいくつかのみを扱います。ここで名前を挙げていない他のエージェントでも同様の脆弱性が見つかっています。

あなたが実行しなかったgit

エージェントがgitに要求する内容は、それが何をしようとしているかによります。現在のブランチ、変更されたファイルやステージングされたファイルを知りたいかもしれません。変更が触れたファイル、リポジトリが追跡しているすべてのパス、またはサブエージェントが作業するための新しいワークツリーを知りたいかもしれません。

多くの例のうち、異なる製品からの2つのサンプルです。

git status --porcelain=2 --branch
git diff --name-only HEAD

どちらも異常ではありません。どちらも自分で書くようなコマンドです。そしてどちらも、ワーキングツリーに触れるほとんどのgitコマンドと同様に、gitにまずインデックスをリフレッシュさせます。

そのリフレッシュがシンクです。

core.fsmonitorは大規模リポジトリのパフォーマンス設定です。ディスク上のすべてのファイルをチェックする代わりに、gitはヘルパープログラムに何が変更されたかを尋ね、インデックスのリフレッシュ中にそれを実行します。これは文書化された、意図された動作です。

Gitはその設定をリポジトリ自身の.git/configから読み取ります。したがって、リポジトリは以下を含めることができます。

[core]
    fsmonitor = <command>

そして、インデックスをリフレッシュするgitコマンド（git status、git diffなど）はそれを実行します。エージェントがどちらを選んだかは関係ありません。そしてcore.fsmonitorだけがこの種の唯一の設定ではありません。そのため、以下の発見の1つはcore.fsmonitorのバグでは全くありません。

配信については正確性を期す価値があります。なぜなら、gitはこれを決して運びません。悪意のあるURLをクローンしても何も起こらず、fetchやpullも同様です。リポジトリは、.gitディレクトリが既に内部にあるファイルとして到着する必要があります。したがって、ベクターはディレクトリをクローンではなく移動するあらゆるものです。共有.zip、共有ドライブ、同期フォルダ、USBスティックなどです。同僚はプロジェクトをこのようにやり取りし、コンサルタントはクライアントに渡します。この記事のすべてのプルーフオブコンセプトで、私たちは.zipを使用しました。

そこからコマンドは、あなたの権限で、あなたのマシン上で、あなたとして実行されます。これはエージェント自身のコードがサブプロセスを起動してgitを使用するため、コマンドはサンドボックスの外で、承認プロンプトなしで実行されます。権限モデルはそれを決して認識しません。

私たちはこれをGitSpawnと呼んでいます。以下に、さまざまなCLI AIエージェントで見つかった例を示します。

実行時にエージェントが実際に行うことを確認したいですか？ Manifoldに問い合わせる。

エージェントごとの同じ間違い

Goose

［動画: Gooseのレビュー機能がワーキング差分を収集し、リポジトリのcore.fsmonitorコマンドがGooseがモデルに連絡する前にホスト上で実行される様子］

シンク。 gooseはgit diffをリポジトリ内で実行してレビュー用の差分を構築しました。core.quotePath=offという1つの設定フラグをgitに渡しましたが、何も削除しませんでした。インデックスがリフレッシュされ、リポジトリのcore.fsmonitorコマンドが、gooseがモデルに連絡する前に実行されました。

トリガー。 ユーザーがワーキング変更のコードレビューを取得するためにgoose reviewを実行し、コマンドが差分を収集している間にペイロードが実行されました。

影響を受けたバージョン 1.41.0（2026年7月13日報告）、1.44.0で修正済み。CVE-2026-72718（メンテナーにより7.0（重大度）と採点され、私たちの報告後に割り当てられました）。

Claude Code - core.fsmonitor

［動画: Claude Codeの起動時のgit statusが、ワークスペースの信頼プロンプトがまだ承認待ちの状態である間にPWNEDマーカーファイルをドロップする様子］

シンク。 Claude Codeは、起動時にgit statusを内部サブプロセスとして実行し、サンドボックス外でリポジトリコンテキストを収集しました。リポジトリの設定を何も削除しませんでした。インデックスがリフレッシュされ、リポジトリのcore.fsmonitorコマンドが、ワークスペースの信頼プロンプトが承認される前にホスト上で実行されました。

トリガー。 ユーザーがclaudeでプロジェクトフォルダを開き、エージェントがコンテキストを収集している間にペイロードが実行されました。

確認済みバージョン 2.1.193、2.1.196で修正済み。2026年6月26日報告、同日提出されたレポートの重複としてクローズされました。

Claude Code - ultrareview

［動画: claude ultrareviewが、要求されたレビューが開始される前に、起動時にリポジトリのコマンドを実行する様子］

シンク。 これはcore.fsmonitorではありません。これは同種の別のgit設定であり、レビューパスでは削除されません。悪意のあるコマンドは、ワークスペースの信頼プロンプトが表示または承認される前でさえ、起動時に実行されます。

トリガー。 ユーザーがリポジトリのレビューを取得するためにclaude ultrareviewを実行し、レビューが開始される前にペイロードが実行されます。

報告日 2026年7月15日（2.1.210）、内部チケットの重複としてクローズされました。9月1日時点の2.1.252でも未修正であることを確認しました。

Hermes Agent

［動画: Hermesが最初のメッセージでリポジトリコンテキストを収集し、インデックスをリフレッシュしてホスト上でリポジトリのcore.fsmonitorコマンドを実行する様子］

シンク。 Hermesはセッションディレクトリでgit statusを実行してリポジトリコンテキストを収集します。リポジトリの設定をそのまま渡します。インデックスがリフレッシュされ、リポジトリのcore.fsmonitorコマンドがホスト上で実行されます。

トリガー。 ユーザーがHermesでリポジトリを開いて最初のメッセージを送信すると、Hermesがコンテキストを収集する際にペイロードが実行されます。

確認済みバージョン 0.18.2（2026年7月19日）、翌日報告。0.21.0（9月1日）でも再確認済み。6つのチャネルにわたる6回の連絡試行にもかかわらず、プライベートGHSAアドバイザリは一度もトリアージされませんでした。CVE-2026-71963（ベンダーではなく、独立したCVE番号割り当て機関であるVulnCheckによって割り当てられました）。未修正のままです。

Qwen Code

［動画: qwenが起動時にgit statusを実行し、ユーザーが認証する前にペイロードが実行される様子］

シンク。 Qwen Codeは起動時にgit statusを実行してリポジトリコンテキストを収集します。リポジトリの設定をそのまま渡します。インデックスがリフレッシュされ、リポジトリのcore.fsmonitorコマンドがホスト上で実行されます。

トリガー。 ユーザーがqwenでフォルダを開くと、起動時に、ユーザーが認証する前でさえペイロードが実行されます。

確認済みバージョン 0.19.6（2026年7月7日）、Alibabaのセキュリティレスポンスセンターに報告され、受理されました。0.22.3（9月1日）でも再確認済み。未修正のままです。

Grok Build

［動画: Grok Buildがプロンプトの最初のキーストロークでリポジトリのコマンドを実行し、メッセージが送信される前にペイロードが実行される様子］

シンク。 Grok Buildはgitを実行してリポジトリコンテキストを収集します。リポジトリの設定をそのまま渡します。インデックスがリフレッシュされ、リポジトリのcore.fsmonitorコマンドがホスト上で実行されます。

トリガー。 ユーザーがGrok Buildでリポジトリを開いてプロンプトの入力を開始すると、最初のキーストロークで、メッセージが送信される前にペイロードが実行されます。

確認済みバージョン 0.2.93。同じクラスの以前の報告（2026年7月1日提出、xAIによって「情報提供」としてクローズ済み）がありました。私たちの報告は7月14日に続き、その重複としてクローズされました。1.0.13（9月1日）でも再確認済み。未修正のままです。

タイムライン表

ここでのすべての発見はプライベートに報告されました。4件はその後修正され、未修正の各件は公開前に最新リリースで再確認されました。名前を挙げていない他のエージェントでも同じ脆弱性が見つかっています。詳細情報は意図的に最小限に抑えています。各セクションにはシンク、トリガー、および録画が含まれており、メカニズムは上記で説明されています。公開していないのは、誰でも同僚に向けられるように用意されたリポジトリであり、異なる設定キーに依存する1つの発見については、それが未修正である間、そのキーの名前は伏せています。

対処法

ファイルとしてリポジトリを受け取った場合。 エージェントでディレクトリを開く前に.git/configを検査してください。プログラム名を指定する設定はすべてそれを実行できます。

AIコーディングエージェントを出荷する場合。 製品がバックグラウンドで行うコンテキスト収集呼び出しで、git設定をサニタイズしてください。例: git -c core.fsmonitor=false status

答え

この研究の開始時に、CLI AIエージェントが起動時に実際に何をするのかという問いを立てました。発火するメカニズムの一つはコンテキスト収集であり、これはバックグラウンドで実行されます。エージェントはこれを行うためにgitを使用します。一部では、何も入力する前、ワークスペースの信頼プロンプトを承認する前、さらには認証する前でさえ実行されます。

脆弱性はモデルにあるのではなく、新しいものでもありません。それは、セッション開始時に作業するためにエージェントが起動するサブプロセスである、通常の配管の下にあります。この記事で調査したすべてのエージェントには、同じフローの何らかのバージョンがありましたが、サニタイズされていませんでした。これが、これが単一ベンダーのミスではなく、広範なものとなっている理由です。

AIコーディングエージェントは定着します。何百万人もの人々が、そのパワーと効率のために採用され、技術者も非技術者も同様に、現在それらを使用しています。それらを安全にするには、継続的な研究が必要であり、それはそれらが実行されるマシン上で何をするかを理解することから始まります。

Manifoldによる支援方法

コーディングエージェントは質問に答えるだけではありません。それらはツールを実行し、プロセスを起動し、起動したユーザーの権限でエンドポイント上で動作します。これが、既存の制御が構築されなかった理由です。EDRは、見慣れた開発者ツールが見慣れたことをしていると認識します。ゲートウェイは、既に許可されている認証済みトラフィックを認識します。どちらも、エージェント自体が実行することを決定したことを見ることはありません。

エージェントが自身で作成しなかったものを受け取る場所ならどこでも、同じパターンが現れます。スキル、MCPサーバー、プラグインはファイルとして到着し、独自の構成を持ち、リポジトリと同様の理由で到着時に信頼されます。成果物は変わりますが、パターンは変わりません。

Manifoldはそのレイヤーを監視します。エージェントが実際に行うこと（実行時）を、その権限が許可することではなく、監視します。Manifoldに問い合わせる。