TL;DR
- 2026年7月14日、セキュリティ企業 Mindgard が Cursor（Windows版）の未修正の脆弱性をフルディスクロージャーで公開した。
- 内容は拍子抜けするほど単純だ。リポジトリの直下に
git.exeという名前の実行ファイルを置いておくと、開発者がそのプロジェクトを Cursor で開いた瞬間に、クリックも確認ダイアログもなくそれが実行される。権限は開発者本人と同じ。 - 根本原因は Cursor 固有のバグというより、Windows の「カレントディレクトリを先に探索する」実行ファイル解決の古典的な弱点（untrusted search path）を、AIコーディングツールが自動で踏み抜いている点にある。同じクラスの問題は Copilot CLI・Gemini CLI・Codex・Kiro でも報告済みだ。
- クラウドエンジニアにとっての本質は「Cursorが危ない」ではない。開発マシンはいまやクラウドの認証情報（OCI のセッショントークン、APIキー、kubeconfig）を抱えた高価値ターゲットであり、そこでの静かなコード実行はテナンシへの侵入口になりうるということだ。
- 本記事では脆弱性の技術的中身と業界の反応を整理したうえで、OCI/クラウド運用でいますぐ引ける防御線を具体的にまとめる。
何が起きたのか
Mindgard の公開したレポート（"Cursor 0day: When Full Disclosure Becomes the Only Protection Left"）によると、脆弱性の仕組みはこうだ。
Cursor はプロジェクトを読み込むとき、Git のバイナリを複数の場所から探す。その探索対象にワークスペース（開いているリポジトリ）そのものが含まれている。したがって攻撃者が悪意あるgit.exeをリポジトリのルートに仕込んでおくと、Cursor はパス解決処理の一環としてそれを自動実行してしまう。警告も承認も、「リポジトリ内の実行ファイルがこれから走る」という気配すらない。しかもプロジェクトを開いている間、一定の周期で繰り返し実行される。
PoC は徹底的に無害に作られている。Windows の電卓（Calculator）をgit.exeにリネームしてリポジトリのルートにコミットしただけ。リポジトリをクローンして Cursor で開くと、電卓のウィンドウが勝手に積み上がっていく。Sysinternals の Process Monitor で見ると、親プロセスCursor.exeがgit rev-parse --show-toplevelの実行時に、仕込まれたバイナリを起動していることが確認できたという。
現実の攻撃では、この電卓がランサムウェアのローダー、認証情報を盗むスティーラー、キーロガーに置き換わる。すべて開発者本人の権限で、通知なしに静かに走る。
「前提条件が厳しい」わけではない
「ルートに攻撃者のバイナリを置く」という前提はハードルに見える。だが Mindgard の指摘は鋭い。見知らぬリポジトリをクローンすることこそ、開発者のマシンにバイナリが着地する最も日常的な経路だ。しかも今は、開発者本人だけでなく AIエージェントが一日中クローンとオープンを繰り返している。攻撃者は事前の足がかりを一切必要としない。誰でも publish できるリポジトリから、あなたの権限で走るコードまでの距離は、思っているより近い。
影響範囲と対応の温度差
Cursor は7百万人以上のアクティブユーザー、100万超の有償ユーザー、5万社以上に使われている。それだけの規模のツールで、修正が極めて容易とされる脆弱性が放置された点が波紋を広げている。
Mindgard のタイムラインによれば、報告は2025年12月15日。以降7か月、197を超えるバージョンがリリースされたが修正は入らなかった。再現は2026年4月30日に Cursor 3.2.16 で確認されており、公開時点の最新テスト版でも生き残っているとされる（ただし Mindgard はそのバージョン名を明示していない）。現行リリースは7月10日の 3.11。Cursor は7月13日に Dark Reading の取材へ「対応中で、追って Mindgard に連絡する」と回答したが、修正時期は示していない。
補足として、この個別バグには2026年7月時点でCVEが割り当てられていない。Cursor が公開している33件のセキュリティアドバイザリを The Hacker News が確認したが、この件に該当する記載はなかった。
なぜ「地味なのに深刻」なのか
この脆弱性の本質は、Cursor のコードの1行ではなく、その下に横たわる古い設計上の弱点にある。
Windows のデフォルトの実行ファイル探索順序は、信頼できるシステムパスより前に「作業ディレクトリ」をチェックする。攻撃者は「探索が見つけに来る場所」に自分のバイナリを置くだけでいい。これは untrusted search path と呼ばれる既知の欠陥で、2020年に Git Credential Manager Core が同じ手口（CVE-2020-26233）で突かれている。手口そのものは何年も前から知られている。
新しいのは「踏み抜き方」だ。従来は開発者が手でコマンドを叩いたときに問題が起きた。いまはIDEやエージェントが、フォルダを開いた瞬間に代わりに探索を走らせてくれる。人間の操作を待たずに実行境界を越える。AIコーディングツールの「積極性」が、そのまま攻撃面の拡大になっている。
Cursorだけの話ではない
セキュリティ企業 Cymulate は2026年6月、同じクラスの問題を GitHub Copilot CLI・Gemini CLI・Codex デスクトップアプリなど複数のAIコーディングツールで報告している。Windows 上でこれらの多くが、ヘルパー実行ファイルをデフォルトの探索順序で解決していた。対応はばらついた。
- Google：Gemini CLI の指摘を有効と認めたが、パッチはリリースせず。
-
OpenAI：Codex の報告を「Not Applicable」でクローズ。理由は「
git.exeを置き換えられる攻撃者はすでにシステムアクセスを持っている」。だが報告されたシナリオはそれではない——クローンがバイナリを届ける、という点が抜けている。 -
AWS：関連する Kiro の指摘に CVE-2026-10591 を割り当て、Kiro 0.11 で修正。ただしこれは別メカニズム（汚染された
.vscode/tasks.jsonがフォルダオープン時に自動実行される問題）だった。 - バイナリ設置系の報告からは、どのベンダーも修正を出していない。
「脆弱性は untrusted search path、攻撃は探索が見つける場所にバイナリを置くこと」——この構図はツールを問わず同じだ。
なお Cursor 自体、直近でも他の実行・機密まわりの指摘が続いている。エージェントターミナル経由でサンドボックスを脱出する DuneSlide（CVE-2026-50548 / 50549）や、インストール済み拡張がローカルの SQLite から API キー・セッショントークン（OpenAI/Anthropic/Google 等）を読めてしまうという LayerX の報告などだ。単発の不具合というより、急速な機能開発がセキュリティレビューを追い越しているパターンとして読むべきだろう。
賛否：Hacker Newsでの議論
この件は HN でも評価が割れた。ここは断定を避け、両論を並べてから中立で締める。
否定的な見方（過大評価では、という立場）
「結局、実行させるには“すでに悪意あるペイロード”が自分のPCに届いている必要がある」という指摘。クローンやダウンロードで届く前提を『マルウェアが手元にある状態』と等価に見なせば、これは新しい脅威ではない、という理屈だ。Cursor には「このリポジトリを信頼しますか？」ダイアログもある。
肯定的な見方（十分に深刻、という立場）
その「届く経路」こそがエージェント時代の常態だ、という反論。人もエージェントも未知のリポジトリを日常的にクローン・オープンする以上、「悪意あるバイナリが手元に届く」ことは特別な前提ではなく初期条件だ。しかも実行にクリックも承認もない。信頼ダイアログについても、Git の探索がトラスト確認の前に走るのか後に走るのかが開示されておらず、保護になる保証がない（確認できるまでは保護されないと見なすべき）。
中立的な総括
筆者の見立てはこうだ。単体バグの CVSS 論争より重いのは、「開いた／クローンしただけで、承認なしにリポジトリ内のコードが走る」という信頼モデルの破れそのものである。加えて、最も単純な部類の報告が7か月放置されたというベンダーの応答性の欠如が、バグ本体以上の露出になっている。HN のコメント欄でも「バグより沈黙のほうが不気味」という声が支配的だった。攻撃の難易度をどう見積もるかに関わらず、防御側の結論は変わらない——Windows ではクローン済みリポジトリを「実行可能コンテンツ」として扱うのが安全側の判断だ。
クラウドエンジニアにとっての本当の怖さ
ここからが本題だ。この脆弱性はWindows上のCursorに閉じた話に見えて、クラウド運用の急所を突いている。
いまの開発マシンは、単なるエディタが載った箱ではない。そこにはクラウドテナンシへの鍵束が置かれている。
-
~/.oci/configに書かれた OCI のAPIキーやプロファイル -
oci session authenticateで得たセッショントークン -
~/.kube/config、各種クラウドCLIの資格情報、.envに散らばったシークレット - SSH秘密鍵、Git のクレデンシャル
開発マシンで静かにコード実行が起きるということは、これら資格情報の窃取と、そこからのクラウドテナンシへの横展開が現実的になる、ということだ。盗まれた鍵の権限が広ければ、被害はローカルでは止まらない。ブラストradius（爆発半径）は、その開発者に付与された IAM 権限とほぼ等しくなる。
つまり守るべきは「Cursorを使うな」ではなく、「開発マシンが1台落ちても、テナンシが芋づるで落ちない構造にする」ことだ。前回の記事で扱った Anthropic の「見えないガードレール」問題と根は同じで、要はユーザーの承認を経ずに何かが走る／何かが変わるという透明性の破れである。
OCI/クラウドエンジニアの実践的防御
原則は3つ。(1) 資格情報を短命・最小権限にする、(2) 未知のコードは使い捨て環境で走らせる、(3) 実行と権限行使を監査可能にする。OCI に落とすと以下になる。
1. ローカルに長寿命の鍵を置かない
長寿命のAPIキーを~/.oci/configに置きっぱなしにするのをやめる。対話作業はセッショントークンに寄せる。
# 長寿命APIキーの代わりに、期限付きのセッション認証を使う
oci session authenticate --region ap-tokyo-1 --profile-name dev-session
# 期限が切れたら都度更新。盗まれても寿命が短い
- ワークロード（Compute / Functions / OKE）はユーザー鍵ではなくインスタンスプリンシパル/リソースプリンシパルで認可する。ラップトップに人間の鍵を残さない。
- APIキーは定期ローテーション。CIやサーバに静的キーを置くのも避け、短命トークンに寄せる。
2. 未知リポジトリは「使い捨て環境」で開く
Mindgard/Cymulate の当面の推奨は明快だ。信頼できないリポジトリは、隔離VMやWindows Sandboxなどの使い捨て環境でのみ開く。ハッシュのブロックリストに頼らない（攻撃者のバイナリはハッシュが毎回変わる）。クラウド側の武器も使える。
- エージェントに未知コードを触らせる作業は、OCI Cloud Shell や、隔離コンパートメント/VCNに置いた使い捨てのdev VM、OKEのdevコンテナに寄せる。母艦のラップトップで直接やらない。
- 開く前にチェックする習慣を。
git.exe・node.exe・npx.exe・where.exeがプロジェクトのルートにいる理由はない。
管理下のWindows端末では、パスベースの拒否ルールで暫定緩和する（ハッシュベースではなく）。
# AppLocker / Windows App Control の例（パス指定で拒否）
# 開発ワークスペース配下からの実行をブロック
%USERPROFILE%\source\repos\*\git.exe
なお「特定の親プロセスから起動されたときだけ子exeをブロックする」ルールは Windows 標準では書けないため、親プロセスを見た制御が必要ならEDRが要る。
3. シークレットをディスクに散らさない
.envにシークレットを平文で置き、それをワークスペースに抱えたまま未知コードを走らせるのは最悪の組み合わせだ。
- アプリのシークレットはOCI Vaultへ。
.envは.gitignoreに入れ、リポジトリにも作業ディレクトリにも極力残さない。 - 「作業ディレクトリにあるものは漏れうる」という前提で棚卸しする。
4. 盗まれた鍵の行使を検知する
侵入を100%防げない前提で、認証情報が悪用された瞬間を捕まえる層を用意する。
- OCI Auditで全API呼び出し（Console/CLI/SDK）を記録し、保持する。
- IAMポリシー変更、想定外リージョンからのアクセス、権限昇格や大量リソース操作などにアラームを張る。
- テナンシ/コンパートメントを分割し、開発者のブラストradiusを構造的に絞る。dev用テナンシやコンパートメントを本番から隔離する。
5. 同じクラスはCIランナーも直撃する
「汚染リポジトリを開いた/走らせた瞬間に、その環境の権限でコードが実行される」という構図は、開発者の端末だけでなくCIランナーでも成り立つ。ランナーはしばしばデプロイ用の強い資格情報を持つ。
- ランナーはエフェメラルに。ジョブごとに使い捨て、状態を持ち越さない。
- パイプラインに静的キーを置かず、**短命トークン（OIDC連携／ワークロードアイデンティティ、あるいはインスタンス/リソースプリンシパル）**で認可する。
- パイプラインのサービス権限は最小スコープに。ビルドがテナンシ全体を触れる構成は避ける。
チェックリスト（OCI/クラウド運用向け）
-
~/.oci/configの長寿命APIキーをセッショントークン運用に置き換えた - ワークロードはインスタンス/リソースプリンシパルで認可し、人間の鍵をサーバ・CIに置いていない
- 未知リポジトリを開く作業を Cloud Shell / 隔離VM / 使い捨てコンテナに隔離している
-
シークレットは OCI Vault にあり、
.envは.gitignore済み - OCI Audit を有効化し、IAM変更・異常アクセスにアラームを張った
- テナンシ/コンパートメント分割で開発者のブラストradiusを絞った
- CIランナーはエフェメラル、認可は短命トークン、権限は最小スコープ
- （Windows端末）AppLocker/App Control のパスベース拒否、必要ならEDRで親プロセス制御
まとめ
Cursor のgit.exe問題は、技術的には「1行で直せる」と評されるほど単純だ。だが、そこから読み取るべき教訓は単純ではない。
- AIコーディングツールの積極性は、そのまま攻撃面になる。人間の承認を待たずにフォルダを開き、探索し、実行する。
- 開発マシンはクラウドの入口であり、そこでの静かなコード実行はテナンシ侵入と等価になりうる。
- だからこそ防御は端末側だけで完結させず、短命・最小権限の資格情報、使い捨て実行環境、監査可能性という、クラウド側の構造で受け止める。
前回扱った「見えないガードレール」も、今回の「見えない実行」も、突き詰めれば同じ問いだ——ユーザーの承認と可視性を飛ばして、何が勝手に走り、何が勝手に変わっているのか。自動化とエージェントの時代において、透明性と制御可能性は「あれば良い」機能ではなく、防御アーキテクチャの前提である。
参考（一次・二次情報）
- Mindgard, "Cursor 0day: When Full Disclosure Becomes the Only Protection Left" — https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left
- The Hacker News, "Cursor Flaw Lets Malicious Cloned Repositories Trigger Windows Code Execution" — https://thehackernews.com/2026/07/cursor-flaw-lets-malicious-cloned.html
- Dark Reading, "Cursor IDE Auto-Executes Malicious Code in Poisoned Repos" — https://www.darkreading.com/application-security/cursor-ide-malicious-code-poisoned-repos
- SecurityWeek, "Unpatched Cursor Vulnerability Exposes Users to Code Execution" — https://www.securityweek.com/unpatched-cursor-vulnerability-exposes-users-to-code-execution/
記事内の脆弱性ステータス（未修正・バージョン等）は2026年7月中旬時点の情報です。Cursor 側の修正状況は変わる可能性があるため、公開前に最新のアドバイザリを確認してください。