Cursorのゼロデイ脆弱性：フルディスクロージャーが唯一の保護手段となる時

Cursor 0day: When Full Disclosure Becomes the Only Protection Left Aaron Portnoy July 14, 2026 Updated: June 17, 2026 誰も修正に関心がないと思われる脆弱性 主なポイント プロジェクトをロードした後、Cursorは現在のワークスペースを含む様々な場所でgitバイナリを検索します。ルートに悪意のあるgit.exeを仕込んだリポジトリを作成することで、IDEはユーザーの操作や確認なしにそれを実行します。これは繰り返し発生します。 セキュリティリサーチでは、何ページにもわたる説明を必要とする深く技術的な脆弱性が発見されることがありますが、これはそのケースではありません。 このバグは単純です。Windows上でCursorにリポジトリを開いた開発者は、そのリポジトリのルートに悪意のあるgit.exeが含まれている場合、Cursorがそれを自動的に実行します。クリック、プロンプト、承認ダイアログ、警告は一切ありません。結果として任意のコードが実行されます。 Cursorは、最も広く採用されているAI支援開発環境の1つ（アクティブユーザー700万人以上、毎日100万人以上、有料ユーザー100万人以上、5万社以上で使用）であり、600億ドルという報告されている市場価格を考えると、ある程度のセキュリティプラクティスへの配慮が存在すると仮定するのは妥当ですが、この問題はそうではないことを示唆しています。 この脆弱性は、Mindgardによって2025年12月15日に初めて特定されました。同日およびそれ以降複数回報告しましたが、6ヶ月以上経過し、197以上の新しいバージョンがリリースされた後も、テストされた最新バージョンでこの問題は依然として存在します。 この脆弱性は理論的なものではなく、複雑なエクスプロイトチェーン、プロンプトインジェクション、モデル操作、ジェイルブレイク、メモリ破損、高度な攻撃者の技術を必要としません。エクスプロイトするには、リポジトリのルートにgit.exeバイナリが含まれるプロジェクトを開発者が開くだけで十分です。 Cursorユーザーが今すぐ取るべき対策 エンタープライズ/管理下のWindowsシステム：管理下のWindowsシステムでは、一時的な緩和策として、管理者はAppLockerまたはWindows App Controlポリシーを使用して、開発者ワークスペースディレクトリから影響を受ける実行可能ファイル名の実行を拒否できます。ハッシュベースの拒否ルールよりも、リポジトリ/ワークスペースのルートにスコープされたパスベースの拒否ルール（例: %USERPROFILE%\\\source\\\repos\\\*\\\filename.exe）を優先してください。攻撃者が提供するバイナリはハッシュが異なる可能性があるためです。Windowsは、特定の親プロセスによってのみ起動された場合に任意の子実行可能ファイルをブロックする一般的な組み込みルールを提供していないため、親を認識した強制には通常EDRまたはカスタムエンドポイントセキュリティ製品が必要です。 コンシューマーシステム：IDEがパッチ適用されるまで、信頼できないリポジトリは隔離されたVM、Windows Sandbox、またはその他の使い捨て環境でのみ開いてください。この問題に対してファイルハッシュブロックリストに依存しないでください。 単純な問題に対する奇妙な対応 この開示で最も混乱するのは、Cursorからの応答がないことです。7ヶ月にわたり、Mindgardは利用可能なすべてのチャネルを通じて繰り返し関与を試みました。最初の開示は、同社が公開しているsecurity.txtファイルに指定されているCursorのセキュリティ報告用メールアドレスに直接送信されました。確認が得られなかったため、フォローアップを送信しました。適切なセキュリティ担当者を特定するために、公開での連絡も試みました。 最終的に、CursorのCISOが応答し、内部の自動化の失敗により、期待されるHackerOneのワークフローが実行されなかったことを認めました。私たちはプライベートバグバウンティプログラムに招待され、レポートを再提出しました。 レポートは当初「Informative（参考情報）」および「out of scope（範囲外）」としてクローズされました。その決定に異議を唱えた後、HackerOneはレポートを再オープンし、問題を再現し、Cursorに詳細が届けられたことを確認しました。そしてすべてが停止しました。アップデートのリクエストは無視され、追加のフォローアップは応答がなく、HackerOneを通じたエスカレーションも有意義な関与を生まず、Cursorのリーダーシップへの直接の連絡も同じ結果でした。応答がありませんでした。 修正が開始された証拠も、エンジニアリングチームが問題を積極的に調査している証拠も、影響を受けるユーザーにリスクが通知される証拠も、数ヶ月経ってもありませんでした。その間、Cursorはリリースを続けました。機能がリリースされ、発表が続き、プラットフォームが進化する中で70以上のバージョンがリリースされました。しかし、脆弱性は存在し続け、ステータスアップデートの繰り返しリクエストは有意義な応答を生みませんでした。 ある時点で、会話は脆弱性の開示から、より不快な質問へとシフトします。セキュリティプロセスは何のためにあるのでしょうか？ バグ 技術的な問題自体は驚くほど単純です。プロジェクトをロードする際、Cursorは複数の場所でGitバイナリを見つけようとします。その場所の1つにワークスペース自体が含まれます。 攻撃者がリポジトリのルートに悪意のあるgit.exeを仕込んだ場合、Cursorは警告、承認、あるいはリポジトリからの実行可能コンテンツが実行されようとしていることの兆候なしに、パス解決ロジックの一部としてそれを自動的に実行します。 問題を安全に実証するために、Mindgardは無害な概念実証（Proof-of-Concept）を使用しました。それは、リポジトリのルートに配置され、git.exeにリネームされたWindows電卓アプリケーションでした。単純にそのリポジトリに対してCursorを起動するだけで、実行するのに十分でした。 以下のスクリーンショットは、その結果を示しています。複数の電卓ウィンドウは、研究者によって手動で開かれたものではありません。プロジェクトが開いたままである間、Cursorはリネームされたバイナリを繰り返し実行し続け、時間とともにインスタンスが増加しました。つまり、これは一度限りの起動イベントやユーザーがトリガーしたアクションではありませんでした。Cursorは通常の操作中に、ワークスペース内の実行可能コンテンツを繰り返し呼び出していました。 無害な概念実証として、Windows電卓をgit.exeにリネームして使用しました。プロジェクトを開いた後、Cursorはリポジトリのルートからバイナリを繰り返し実行しました。 実際の攻撃シナリオでは、電卓は単に攻撃者が制御するコードに置き換えられるでしょう。 以下に示すSysinternalsプロセスモニターログ（2026年4月30日、Windows上のCursorバージョン3.2.16で最後に検証）で実証されているように、結果は現在のユーザーの権限下での任意のコード実行です。 4:25:12.6209706 PM Cursor.exe 54880 Process Create c:\Users\aport\Documents\Audits\cursor\test_repos\git_exec0001\git.exe SUCCESS PID: 48972, Command line: git rev-parse --show-toplevel "C:\Users\aport\AppData\Local\Programs\cursor\Cursor.exe" C:\Users\aport\AppData\Local\Programs\cursor\Cursor.exe この脆弱性は、その単純さゆえにほとんど退屈であり、それが最も懸念すべき部分かもしれません。通常の操作中に、Cursorはユーザーの操作を必要とせずに、リポジトリ内の攻撃者が制御するバイナリを実行します。このような単純な問題が、修正なしに数ヶ月も存続できるという事実は、現在Cursorを展開しているすべての個人および組織を懸念させるべきです。 この開示が異なる理由 ほとんどの協調的な開示は、よく知られたパターンに従います。 脆弱性が報告される。 対話が始まる。 深刻度が議論される。 エンジニアリングチームが調査する。 修正が開発される。 ユーザーが保護される。 その後、公開開示が行われる。 このプロセスは、すべての関係者が共通の目標、すなわちリスクの低減を共有しているため機能します。 残念ながら、このケースはリスク低減の段階に達しませんでした。7ヶ月が経過し、ベンダーからの関与がない中で、これほど単純で影響の大きい脆弱性の修正がいつか行われるのか疑問視する時期が来ています。 セキュリティ研究者は、特に大規模で急速に進化するソフトウェアプラットフォーム内では、修正に時間がかかることを理解しています。しかし、コミュニケーション、アップデート、進捗の兆候なしに数ヶ月が経過した場合、忍耐は正当化するのが難しくなります。ユーザーは基本的な脅威に対する基本的な保護を受ける権利があり、ベンダーが影響を受けるソフトウェアの配布を続けながらコミュニケーションを停止した場合、研究者は最終的に不快な選択に直面します。 沈黙を守り、ユーザーに安全性の誤った認識の下で運用させる。 または、組織が情報に基づいたリスク判断を行えるように、問題を公に開示する。 私たちは、ユーザーは情報を受ける権利があると信じています。フルディスクロージャー