Cursor IDEで最近公表されたセキュリティ問題により、深刻なWindowsバイナリプランティングの脆弱性が明らかになり、悪意あるコードが実行され得ることが分かりました。信頼されていないリポジトリを開くだけで実行されてしまうというものです。
この脆弱性はCVE-2026-63093として追跡されており、Cursorの実行ファイル解決処理の挙動に関連するものです。攻撃者が管理するファイルをワークスペース内に配置することで、現在のユーザー権限で実行される可能性があることが実証されています。
Cursorのゼロデイ脆弱性
AIセキュリティ企業のMindgardは、2025年12月15日にこの問題を最初にCursorへ報告し、2026年7月14日に技術詳細を公表しました。
Cloudsecurity services
当初の概念実証(PoC)では、悪意ある`git.exe`をリポジトリのルートに設置する手法が使われていました。Cursorがワークスペースを開くと、`git rev-parse –show-toplevel`を含むGit関連のコマンドが実行される仕組みです。
Windowsでは、実行ファイルの検索処理において現在の作業ディレクトリが優先される場合があります。そのため、Cursorが完全修飾された信頼済みパスを指定せずに`git.exe`を呼び出すと、システムにインストールされている正規のGitバイナリよりも先に、開いているリポジトリ内に置かれた不正な実行ファイルが見つかってしまう可能性があります。その結果、プロジェクトを開いた開発者のセキュリティコンテキストでコードが実行されてしまいます。
さらなる検証により、この脆弱性は`git.exe`に限定されないことも判明しました。特定の条件下では、開いたフォルダ内に`pyproject.toml`のようなPythonプロジェクトの設定ファイルを検知すると、Cursorが`hatch.exe`の実行を試みる場合もあります。
悪意あるリポジトリには、一見シンプルな2つのファイルが含まれる可能性があります。
malicious-repository/
├── hatch.exe
└── pyproject.toml
このケースでは、`pyproject.toml`ファイルは明白なペイロードというより、あくまで引き金として機能します。Hatchツールを参照する基本的なビルドシステムの宣言があるだけで、Cursorが`hatch.exe`を探しに行く可能性があるのです。
アプリケーションが安全でない実行ファイル検索処理を使用している場合、ワークスペース内の悪意ある`hatch.exe`が自動的に実行されてしまう恐れがあります。
この点が特に懸念されるのは、リポジトリ内に悪意あるVS Codeタスクや起動スクリプト、不審なシェルコマンドといった、よく知られた高リスクの痕跡が含まれていない場合があるためです。
Screetsecによると、プロジェクト設定は一見正当なものに見える一方で、実行ファイルは依存関係に関連する通常のユーティリティを装って隠されている可能性があるとのことです。
ワークスペーストラストは、信頼されていないコードやプロジェクト設定に対する安全対策として提示されることが多い機能です。しかし、CursorとTrae IDEを対象にした調査により、この信頼制御機能だけでは実行ファイル検出の挙動という問題を完全にはカバーできない可能性があることが明らかになりました。
Traeではワークスペーストラストがデフォルトで有効になっており、ワークスペース起点の一部の実行パスが有効になる前に、ユーザーが信頼するフォルダを選択する必要があります。
これに対し、Cursorではワークスペーストラストがデフォルトで無効になっていたと報告されています。そのため、実証された挙動はゼロクリックのシナリオに近いものとなっていました。リポジトリを開くだけで実行がトリガーされてしまうのです。
重要なのは、ワークスペースが信頼済みとしてマークされているかどうかではなく、IDEが攻撃者の管理下にあるディレクトリを検索して実行ファイルを探し、ユーザーの明示的な承認なしに起動してしまうかどうかという点です。
防御側は、Cursorから生成される`git.exe`だけを監視対象とするべきではありません。この方法では、Python、パッケージ管理、ビルドツール、あるいは言語固有のユーティリティを介した別の実行経路を見落としてしまう可能性があるためです。
セキュリティチームは、IDEプロセスがリポジトリのルート、ダウンロードフォルダ、一時ディレクトリ、その他の非標準的なパスから実行ファイルを起動するプロセス生成の動きを監視すべきです。また開発者側も、リポジトリを開く前に、特に一般的な開発ツールと同じ名前を持つファイルがないかなど、想定外のバイナリが含まれていないか確認すべきでしょう。
Cloudsecurity services
Cursorは、既知のファイル処理および実行ファイル検出に関する脆弱性について、後続のリリースで対処済みだと報告されています。とはいえ、今回の調査結果は、IDEベンダーにとってより広範な教訓を示しています。プロジェクトのコンテンツは単なる受動的なソースコードではなく、実行され得るものとして扱うべきだということです。
新たなフィッシングやマルウェアが自社を侵害する前に阻止しましょう。 世界15,000のSOCからのリアルタイムインテリジェンスを統合
翻訳元: https://gbhackers.com/cursor-0-day-lets-attackers-execute-malicious-code/
