- Windows版Cursorはプロジェクトを開く際、ワークスペースのルートにある
git.exeを自動実行するため、悪意あるバイナリを含むリポジトリを開くだけでユーザー操作なしに任意コードが実行される可能性がある
- Gitのパス探索範囲にリポジトリ内部が含まれており、警告や承認なしにファイルを実行するだけでなく、プロジェクトを開いている間は定期的に再実行する
- Mindgardは2025年12月15日に報告し、HackerOneを通じて再現・連携まで完了したが、6か月以上と197件以上の新バージョンを経た後も、最新のテスト版に問題が残っていた
- 管理されたWindows環境では、AppLockerやWindows App Controlのパスベース拒否ルールを適用し、一般ユーザーはパッチ適用まで信頼できないリポジトリをVMまたはWindows Sandboxで開く必要がある
- 調整された公開手順ではユーザーリスクを下げられないと判断したMindgardは、すべての詳細を公開した。AI開発ツールを選ぶ際は、ベンダーのセキュリティ対応とコミュニケーション能力も信頼基準にすべきである
リポジトリを開くだけで実行されるgit.exe
- Cursorはプロジェクトを読み込む際、複数の場所からGitバイナリを探し、検索対象には現在のワークスペースも含まれる
- 攻撃者がリポジトリのルートに悪意ある
git.exeを配置すると、Cursorは警告や承認ダイアログ、追加のクリックなしにそれを自動実行する
- 開発者がそのプロジェクトを開くだけで攻撃が始まり、プロンプトインジェクションやモデル操作、脱獄、メモリ破損、複雑なエクスプロイトチェーンは不要である
- 実行されたコードは、現在のCursorユーザーの権限範囲で動作する
再現手順と反復実行の記録
- Mindgardは安全な概念実証のため、Windows Calculatorを
git.exeにリネームしてリポジトリのルートに配置した
- Cursorでそのリポジトリを開くとCalculatorが起動し、プロジェクトを開いたままにすると複数のウィンドウが追加で表示された
- 研究者が複数のウィンドウを手動で開いたわけではない
- 一度きりの起動動作ではなく、通常使用中にワークスペース内の実行ファイルを定期的に再実行した結果である
- 実際の攻撃では、Calculatorの代わりに攻撃者が制御するコードを配置できる
- Sysinternals Process Monitorの記録には、
Cursor.exeがリポジトリ内部のgit.exeを実行し、次のコマンドを渡した履歴が残っている
git rev-parse --show-toplevel
- 最終検証は2026年4月30日、Windows版Cursor 3.2.16で行われた
大規模なユーザー基盤に残っていた脆弱性
- Cursorは次の規模で利用されているAI支援開発環境である
- アクティブユーザー700万人以上
- デイリーユーザー100万人以上
- 有料ユーザー100万人以上
- 利用企業5万社以上
- 報じられた市場価値は600億ドルである
- Mindgardは2025年12月15日に脆弱性を発見し、同日に報告した
- 冒頭時点で、6か月以上と197件以上の新バージョンを経た後も、最新のテスト版に脆弱性が残っていた
- 対応経過を扱う本文には、機能追加や発表が続く間に70件以上のバージョンがリリースされたにもかかわらず、問題が維持されたと記録されている
- 単純で再現しやすい任意コード実行の脆弱性が数か月にわたり修正されず、Cursorを導入した個人・組織の双方が影響を受けた
パッチ前に適用できる暫定対策
- 管理されたWindowsシステムでは、AppLockerまたはWindows App Controlポリシーにより、開発ワークスペースディレクトリ内の該当実行ファイル名をブロックできる
- バイナリごとにハッシュが異なる可能性があるため、ハッシュベースのブロックリストよりも、リポジトリ・ワークスペースのルートに範囲を限定したパスベース拒否ルールが適している
%USERPROFILE%\\source\\repos\\*\\filename.exe
- Windowsには、特定の親プロセスが実行した場合にのみ任意の子実行ファイルをブロックする一般的な組み込みルールはない
- 親プロセスを認識する制御には、EDRまたはカスタムのエンドポイントセキュリティ製品が必要である
- 一般ユーザーは、IDEがパッチされるまで信頼できないリポジトリを隔離されたVM、Windows Sandbox、または使い捨て環境でのみ開くべきである
- バイナリを差し替えるたびにハッシュが変わる可能性があるため、この脆弱性ではファイルハッシュのブロックリストを信用すべきではない
報告後に停止してしまった調整手順
- 最初の報告はCursorのsecurity.txtで指定されたセキュリティ報告用メールアドレスに送られたが、受領確認はなかった
- Mindgardは追跡メールと公開の連絡要請を通じて、適切なセキュリティ担当者を探そうとした
- CursorのCISOは、内部自動化の失敗により予定されていたHackerOne手順が開始されなかったと回答し、Mindgardを非公開のバグバウンティプログラムに手動で招待した
- HackerOneに再提出した報告は、当初Informativeかつ対象外としてクローズされた
- Mindgardはその判定に異議を申し立てた
- HackerOneが問題を再現した後、報告を再オープンし、詳細がCursorに共有されたことを確認した
- その後、更新要求やHackerOne経由のエスカレーション、CursorのCISOおよび経営陣への直接連絡にも、意味のある回答はなかった
- Mindgardは、修正が開始された、エンジニアリングチームが調査中である、または影響を受けるユーザーにリスクが伝達されたという証拠を得られなかった
報告から完全公開までのスケジュール
-
2025年12月15日
- Mindgardが脆弱性を発見
security-reports@cursor.comへ報告
-
2025年12月18日
-
2026年1月13日
- Cursorの連絡担当者を探すためLinkedInに投稿
- コメントであるユーザーがCursorのCISOを示した
-
2026年1月15日
- CursorのCISOが、HackerOneの非公開バウンティ招待自動化の失敗を伝え、手動で招待
- MindgardがHackerOne経由で脆弱性を提出
-
2026年1月16日
- 報告がInformativeかつ対象外としてクローズ
- Mindgardが判定に異議申し立て
- 再現成功後に報告が再オープン
-
2026年1月20日
- HackerOneがCursorに報告を送達したと確認
-
2026年2月16日、3月3日
-
2026年3月17日
-
2026年3月18日
-
2026年4月1日
- Mindgardが再び更新を求めたが返答なし
- HackerOneもCursorから更新がないことを確認
-
2026年6月1日
- Mindgardが公開の意思をHackerOneに通知
-
2026年6月3日
-
2026年7月14日
調整された公開がユーザー保護につながらなかった理由
- 一般的な調整公開は、報告、対話、深刻度の議論、エンジニアリング調査、修正開発、ユーザー保護、公開の順で進む
- この手順は、すべての参加者がリスク低減という目標を共有しているときに機能する
- 今回の事例では、7か月間にわたりベンダーの意味ある関与がなく、リスク低減の段階まで進めなかった
- 大規模で急速に変化するプラットフォームでは修正に時間がかかる可能性はあるが、数か月間にわたりコミュニケーションや更新、目に見える進展がない状況では、待ち続けるのは難しい
- 研究者には二つの選択肢しか残されなかった
- 沈黙を保ち、ユーザーが安全だという誤った前提のもとで作業を続けるのを許す
- 公開によって組織がリスクを把握し、対応の要否を判断できるようにする
- Mindgardは、ほかのすべての経路が失敗したときに用いる完全公開を選んだ
バグバウンティとAIセキュリティ対応体制が残した問い
- 解決が遅れた原因として、次の可能性が問われている
- 現代のバグバウンティプログラムは過負荷状態なのか
- Mythosのように能力が高まったモデルのため、報告件数を処理しきれなくなっているのか
- CursorがSpaceX買収に集中するあまり、ユーザー安全の優先順位を下げたのか
- 数十億ドルが絡む状況で、ユーザー安全は本当に関心事なのか
- AI製品の拡大により、セキュリティ上の発見件数は大きく増えており、その多くは既存の脆弱性分類にきれいには当てはまらない
- 約20年間依存してきた分類・受理手順は、AI環境で前提が揺らぐにつれ急速に機能不全に陥っている
- 公開パイプラインが過負荷状態なら、業界はそれを透明に知らせ、研究者・顧客・ユーザーが状況を判断できるようにすべきである
- 急成長する企業は、セキュリティ上の失敗を是正すると同時に、ユーザーを購入実験の対象ではなく価値ある顧客として扱うべきである
AI開発ツールを信頼するための条件
- AI企業は、コードやリポジトリ、ターミナル、秘密情報、ワークフローに対して前例のない広いアクセス権を要求し、提案と実行の境界も次第に曖昧になっている
- ユーザーは本番ソフトウェアに、ソースコードや認証情報、独自知的財産、ますます自律化する機能を委ねている
- 生産性を高めるという理由だけでシステムを信頼してはならず、セキュリティ報告への対応、影響を受けるユーザーとのコミュニケーション、修正の優先順位付けを通じて信頼を得る必要がある
- 信頼には責任が必要であり、責任にはコミュニケーションが必要だが、ユーザー・研究者・公開プラットフォームが数か月にわたり基本的なステータス更新すら受け取れないなら、その責任を確認するのは難しい
- Mindgardは、組織が露出範囲を評価し、補完的統制を適用し、セキュリティ状態を判断する機会を与えるため、すべての詳細を公開した
- 情報を隠し続けることがユーザーではなく沈黙だけを守る段階に至ったなら、不都合であってもユーザー安全を優先すべきである
1件のコメント
Hacker News の意見
セキュリティ報告を受ける側として、LLM が生成した低品質な報告が手に負えないほど押し寄せており、たいていは製品設計やセキュリティ上のスコープを理解していない内容である。まれに非常に良い報告もあるため、すべて人手で確認しなければならないが、LLM が作った冗長な「根拠」をさらに送ってくるやり方は解決策ではなく、この記事も大半が LLM で書かれたように見える
今回の件も、ソフトウェアが任意のコードやバイナリを実行できる環境に悪意あるバイナリを置いた場合の話であれば、Cursor がユーザー環境のセキュリティまで責任を持つと言わない限り、ワークスペースを隔離して保護する側の責任に近いように見える
LLM で CVE 報告書を作るときは、決定的に再現する手順に活用し、本文は自分で簡潔に書き、LLM 特有の不要な形容詞や誇張を取り除いてほしい
問題の根は、Cursor がリポジトリのクローンとコード実行を別々のセキュリティ境界として見ていない点にある。Cursor はデフォルトで Workspace Trust を無効化しており[0]、
.vscode/tasks.jsonに"runOn": "folderOpen"が入ったリポジトリを開くだけで、すでに任意のコードが実行される[1][0] https://cursor.com/docs/agent/security#workspace-trust
[1] https://www.oasis.security/blog/cursor-security-flaw
Mindgard は2025年12月15日に脆弱性を初めて発見し、当日およびその後複数回報告したが、6か月と197以上の新バージョンが経過した後も最新の Cursor に残っているという
当初は情報提供扱い・対象外の報告としてクローズされ、異議申し立て後に HackerOne が再オープンして再現し、Cursor に伝えたものの、その後の更新依頼、追加問い合わせ、HackerOne 経由でのエスカレーション、Cursor 経営陣への連絡まで、いずれも返答がなかったというのだから、Cursor がなぜこのように対応しないのか理解しがたい
その結果、企業は以前のようには応答しなくなっており、6月のサイバーセキュリティ会議でも、責任ある開示は死んだ、あるいは死につつあるので、公に明かしたほうがよいという雰囲気が強かった。Microsoft と Nightmare Eclipse の件がよく引用されていた
git.exeを入れて、標的にクローンさせればペイロードを実行できるCursor が VS Code ベースである以上、VS Code でも同じことが起きるのか気になる
これが重大な脆弱性だという点に完全には同意しにくい。実際に悪用するには、攻撃者がユーザーのコードフォルダに
git.exeという悪意ある実行ファイルを先に置く必要があり、これは.bashrcを変更してlsが/tmp/mega-big-virus.shを実行するようにエイリアスを作ることを脆弱性と呼ぶのに近い攻撃経路であることは確かだが、そのようなファイルがすでにファイルシステムに入っているなら、先行侵害が起きている状態と見なせる
autorun.exeが実行され、Windows が感染するのと同じであるすべてのリポジトリファイルと
git.exeのような怪しいバイナリをユーザーが隔離環境で自分で検査すべきだとも言えるが、現実にはユーザーではなく自動実行を防ぐセキュリティポリシーがこれを制御しており、Cursor も同様に無効化すべきである.bashrcと違い、コードフォルダは信頼できない出所から頻繁に取得する。GitHub プロジェクトをレビューしようとして開いただけで、任意コード実行まで許可してはならないただし主要な IDE では、こうした境界はすでにかなり前から崩れており、VS Code の SSH や devcontainer のリモート機能も設計上、リモートコード実行を許可している
git.exeを置くと、ユーザー入力や確認なしに実行すると、2文で明確に述べている。中核となる挙動を隠した記事ではないCursor が確認なしに任意の実行ファイルを実行するのはおかしいし、研究者が数か月にわたってまともな回答を得られなかったことも懸念される
ただし電卓を起動する例はやや誤解を招く可能性がある。悪意ある実行ファイルはすでにシステムにダウンロードされている必要があり、Cursor が実行を試みると ACL が機能し、署名されていない新しいアプリを初めて実行するかどうか権限を求めるはずだと理解している。実際の悪用にはACL が完全に無効化されている必要があるかもしれない
git.exeを実行しますか？」と出たら、Cursor が Git を必要としているのに権限設定がこじれているのだと思い、そのまま承認する可能性が高いCursor固有のバグというより、Windows が PATH を見る前に現在の作業ディレクトリで実行ファイルを探す、Windows 特有の検索順序に関係しているように見える。Windows の多くのプログラムが同様の攻撃にさらされる可能性が高い
https://go.dev/blog/path-securityで説明されているように、
CommandとLookPathは OS の慣例に従って現在の PATH に列挙されたディレクトリからプログラムを探すが、現代ではカレントディレクトリを含める挙動はたいてい想定外であり、セキュリティ問題につながるhttps://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
企業がセキュリティを優先しないことはあまりにもよくあり、残念だが理解できる面もある。セキュリティスタートアップが待ちくたびれて、投下コストの一部でも広報効果として回収しようと公開するのも理解できるし、公開による脆弱性開示が必要な場合もある
ただ、本当に解決を助けたかったのであれば、HackerOne で催促し、CISO に LinkedIn メッセージを一度送る以上のことはできたように思う。今となっては、誰も本気で気にしていないように見えて苦い気持ちになる
Cursor がなぜ実行ファイルを自動実行するのか、どのような意思決定フローからこの挙動が生まれたのかが気になる。Vim も
%{expr}のような明示的機能により、ファイル読み込み時に予期しないコードを実行してしまう問題があったが、Cursor がなぜよりによってgit.exeを探すのか、誰の役に立つ機能なのか理解しにくい簡単に修正できそうな重複的な CVE がなぜ存在するのか、Cursor を使ったことがない立場でも気になってくる
問題は、リモートリポジトリを評価させたときに、リポジトリを clone した後、作業ディレクトリで
git ...を実行すると、Windows がそのディレクトリ内のgitファイルを実行対象と判断し得る点にある。信頼していないリポジトリや侵害されたブランチに切り替える場合にも、即座にコードが実行される可能性がある一般的な解決策は、システムにインストールされた Git の完全なパスを使うことであり、人間が入力するには面倒でも Cursor にとっては些細な作業である
開発エージェントには Git リポジトリを取得・push する権限を与えることが多いだけに、これは巨大なサプライチェーン攻撃経路になる。実行中の Cursor エージェントが最新ファイルを取得したところ、攻撃者がプロジェクトに実行ファイルを仕込んでいたなら、突然数十万人が通常ユーザー権限で任意の EXE を実行し得る
レポートはいささかAI が書いた文章のように読める。悪用するには clone やダウンロードなどを通じて悪性ペイロードがすでに PC 上にある必要があるため、深刻さは理解するが、そもそもそのような状況に置かれないことを期待してしまう
git cloneした後、Cursor で開くだけで侵害は完了するgit.exeを含むプルリクエストを受け取る可能性もあるdownload [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;)のようなコマンドに誘導できるなら、エージェントがgit.exeをダウンロードして実行する可能性がある