Cursor IDE 0day脆弱性により、悪意のあるリポジトリを開くだけで任意のコード実行が可能
- Ethan Carter
- 1 日前
- 読了時間: 3分
Cursor IDEにはゼロデイ脆弱性があり、攻撃者はWindows上で悪意のあるリポジトリを開くようユーザーを騙すだけで、任意のコードを実行できます。フォルダが読み込まれた後はクリックや明示的な承認は一切不要です。
セキュリティ企業Mindgardは2025年12月15日にこの問題を発見しました。脆弱性の原因は、CursorがGitバイナリを検索する際にワークスペース自体を含む多数のフォルダを対象とする点にあります。
対話なしでコードを実行させる脆弱性の仕組み
Cursorはプロジェクトを開く際に複数の場所でgit.exeを検索します。そのうちの1つが現在のワークスペースフォルダです。攻撃者はリポジトリ内に悪意のあるgit.exeを配置できます。
ユーザーがフォルダをクローンまたは開くと、Cursorは攻撃者のファイルを自動的に実行します。これはWindows上でワークスペースの場所が安全なシステムパスよりも優先される検索順序によるものです。
リポジトリが最初に読み込まれた後は、攻撃にユーザーの追加操作は一切必要ありません。研究者は現在のWindowsビルドでこのベクターを検証し、一貫した実行を確認しています。
タイムラインが示す繰り返しの報告と遅い修正
Mindgardは7か月以上にわたりCursorに複数回連絡しました。企業のCISOは報告を認識したものの、社内自動化の不具合により問題がエンジニアリングキューに到達しませんでした。
その期間中に70を超える新バージョンがリリースされましたが、検索順序の修正やGitバイナリの検証はどれも行われませんでした。
Cursorは今日も修正なしで提供されています。内部での修復に進捗が見られなかったため、開示は完全な公開ステータスに移行しました。
ユーザーが今すぐ取れる実践的な手順
AppLockerルールにより、ワークスペースディレクトリからのgit.exeという名前のファイルの実行をブロックできます。このポリシーは、Cursorが呼び出そうとしても悪意のあるバイナリの実行を防ぎます。
信頼できないリポジトリを分離された仮想マシンで実行することも露出を制限します。コードが起動した場合でも、仮想マシンがホストシステムを保護します。
macOS上のCursorユーザーは、検索パスの動作がWindowsと異なるためリスクが低くなります。Linuxビルドでは、ワークスペースパスがバイナリ検索で優先される場合に同様の露出があります。
IDEの検索ロジックが継続的なリスクを生む理由
多くのエディタはGitなどのツールを見つけるためにシステム環境変数に依存しています。Cursorはそのロジックを速度向上のためにプロジェクトフォルダにも拡張しています。この柔軟性の追加は、未知のソースからリポジトリが届く場合に攻撃対象領域を拡大します。
類似のパターンは、バイナリを自動検出する他の開発者ツールでも見られています。いずれの場合もリスクを低減するには明示的な許可リストまたはハッシュチェックが必要でした。
Cursorは新しい安全策や計画リリース日を説明する公式声明を発表していません。ベンダーは元の検索順序を変更しないままアップデートを提供し続けています。
開示後に残る不明点
Mindgardは完全な概念実証や攻撃チェーンを公開していません。同じ検索を通じてCursorが検出する可能性のある他のバイナリの正確な範囲は不明です。
同社がワークスペースのバイナリ検索を制限する予定か、ユーザー側ポリシーのみに依存する予定かも不明です。他のIDEベンダーとの調整された開示タイムラインも発表されていません。
未知の貢献者からリポジトリを開く開発者は、今日から緩和策を適用すべきです。この問題は、検索パスが未チェックのままである場合、IDEの利便性機能が標準的なオペレーティングシステムの保護を損なう可能性を示しています。