CursorのCVE-2026-26268はGit hooksでAIエージェントのサンドボックスを抜ける

TL;DR

---

CursorのCVE-2026-26268は、2026年2月に修正済みの脆弱性だ。
ただ、4月28日にNoveeが攻撃経路を詳しく書いたことで、単なる「古いCursorを更新しよう」以上の話になった。

問題はAIエージェントがGit操作を自律的に実行するところにある。
人間が目で見て git checkout や git commit を打つ前提なら、Git hooksは昔からある普通の自動化機能だ。
でもAIエージェントがリポジトリ内の指示を読み、必要そうなGit操作を勝手に走らせると、.git 配下は「設定ファイル」ではなく実行境界になる。

Cursor 2.5未満では、サンドボックス内の悪意あるエージェント、たとえばプロンプトインジェクションを受けたエージェントが、保護不足の .git 設定を書き換えられた。
Git hooksまで書き込めると、次にGitがそのhookを発火した瞬間、サンドボックス外でコード実行につながる。
GitHub Advisoryは「No user interaction」としており、Gitがhookを自動実行するため、ユーザーの追加クリックや確認は要らない。

Git hooksが実行境界になる

Git hooksは、pre-commit、post-checkout、pre-push などのイベントで自動実行されるスクリプトだ。
通常の開発ではフォーマッタ、テスト、コミットメッセージ検査に使う。便利だが、実行されるものはただのシェルスクリプトでもある。

今回のポイントは、Git hooksそのものが新しい機能ではないことだ。
危ないのは、AIコーディングエージェントがリポジトリの中身を「作業指示」として読み、Git操作まで自律実行する状況と組み合わさる点にある。

Noveeの説明では、悪性リポジトリにbare repository（作業ツリーを持たない素のGitリポジトリ）を埋め込み、その中に悪意あるhookを置く。
さらにCursor Rulesでエージェントの行動を誘導し、エージェントが通常作業の一部としてGit操作を走らせる。
このときhookはGitの正規機能として発火する。

flowchart TD
    A["悪性リポジトリを開く"] --> B["Cursor Rulesが<br/>エージェント動作を誘導"]
    B --> C["エージェントが<br/>Git操作を実行"]
    C --> D["埋め込みbare repository内の<br/>Git hookが発火"]
    D --> E["開発者端末で<br/>任意コード実行"]

    style E fill:#991b1b,color:#fff

これはClinejectionと同じく、AIに直接「悪いことをしろ」と命令するだけの話ではない。
自然言語、CI/CD、Git、npm、IDE設定のような既存の部品がつながったときに、どこかの信頼境界がずれる。
CVE-2026-26268では、そのずれがローカルIDEとGit hooksの間に出た。

CVSSが2種類ある

GitHub AdvisoryではCVE-2026-26268の深刻度はHigh、CVSS 3.1は8.0になっている。
ベクターは CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H で、攻撃複雑度と必要権限が高めに置かれている。

一方でNVDは、2026年2月18日の初期分析で9.9 Criticalを付けている。
こちらのベクターは AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H。
同じCVEでも、CNAであるGitHubとNVDで攻撃条件の見積もりが違う。

この差はかなり大きい。
GitHub側は「悪性エージェントが .git 設定を書ける」という前提を重めに見ている。
NVD側は、AI IDEがリポジトリを開いてエージェントが操作する状況を、より低いハードルとして評価しているように見える。

個人的には、開発者が未知のリポジトリをCursorで開く運用なら、NVD寄りに見たほうが現実に近い。
AIエージェントの「便利な自動実行」は、攻撃者から見ると人間の確認を飛ばす実行装置でもある。

2.5未満なら更新だけで終わらせない

修正はCursor 2.5で入っている。
新規に使う端末なら更新でよい。

すでに2.5未満のCursorで不明なリポジトリを開いていた場合は、既存リポジトリの .git/hooks/ を見る。
知らない pre-commit、post-checkout、post-merge、pre-push が増えていないか。
実行権限が付いたスクリプト、難読化されたシェル、外部通信、curl | sh、osascript、PowerShell、認証情報を読む処理があれば削除前に退避して調査する。

Git設定も見る。
core.hooksPath が変な場所を向いていると、.git/hooks/ だけ確認しても見落とす。

git config --local --list --show-origin
git config --local --get core.hooksPath
ls -la .git/hooks

複数リポジトリを扱う端末では、少なくとも最近Cursorで開いた作業ディレクトリを優先して確認する。
開発端末にはGitHubトークン、npmトークン、クラウド認証情報、SSH鍵が残りがちなので、ローカルRCEは社内ネットワーク侵入より手前の問題では済まない。

サンドボックスはGitを特別扱いしないと抜け道になる

AIエージェントのローカル隔離実行では、macOSの sandbox-exec やWindowsサンドボックスでファイルシステムを縛る話を書いた。
CVE-2026-26268を見ると、ワークスペース全体に書き込みを許すだけでは足りない。
.git は単なるプロジェクト内ディレクトリではなく、次のGit操作でコード実行に変わる設定領域だ。

OpenClaw向けのNemoClawサンドボックスでも、ファイルシステム制限だけではプロンプトインジェクション型の攻撃を防げないと書いた。
今回のCursorはさらに具体的で、.git 配下への書き込みがサンドボックス脱出の足場になった。

AI IDEやコーディングエージェントのサンドボックスでは、少なくとも .git/config、.git/hooks/、core.hooksPath、サブモジュール設定、bare repositoryの扱いを別枠で制限する必要がある。
通常のソースファイルと同じ権限で扱うと、「コードを書ける」権限が「ホストでコードを実行できる」権限に化ける。

参考

• GitHub Advisory: GHSA-8pcm-8jpx-hv8r
• NVD: CVE-2026-26268
• Novee: Your AI Coding Agent Will Run This Exploit For You