CurXecute IDE乗っ取り
AI開発環境そのものが攻撃対象になる
これまでの事件は、vibe codingで 作られたアプリ の脆弱性でした。
しかし2025年7月、新たな脅威が明らかになりました。
vibe codingに使う 開発ツールそのもの が攻撃対象になったのです。
CursorはIDEとして人気のあるAIコーディングツールですが、重大な脆弱性が発見されました。
CVE-2025-54135: CurXecute
2025年8月1日、セキュリティ企業AIM Securityは脆弱性を公開しました。
CVE-2025-54135（CurXecute）
- 深刻度：8.6（High）
- 影響：リモートコード実行（RCE）
- 対象：Cursor IDE
この脆弱性により、攻撃者は 開発者のマシン上で任意のコマンドを実行 できました。
攻撃の仕組みと脆弱性のメカニズム
CurXecuteの攻撃フローは巧妙でした。
攻撃手順:
- トリガー — 攻撃者がSlackメッセージや外部コンテンツに悪意のあるプロンプトを埋め込む
- 処理 — 開発者がCursorでそのコンテンツを要約させる
- 書き換え — AIがMCP設定ファイル（
~/.cursor/mcp.json）を書き換え - 実行 — 新しいMCPサーバーが起動し、任意のコマンドを実行
驚くべきことに:
「Cursorは新しいMCPエントリの実行に確認を求めない。ユーザーが編集を拒否しても、提案されたエントリがトリガーされる」
つまり、ユーザーが「拒否」を押しても攻撃が成功する 可能性がありました。
攻撃サーフェスの広さ
この脆弱性の影響範囲は広大でした。
「攻撃サーフェスは、外部コンテンツを処理するあらゆるサードパーティMCPサーバーだ。イシュートラッカー、カスタマーサポートの受信箱、検索エンジンさえも」
攻撃経路の例:
| 経路 | 説明 |
|---|---|
| Slackメッセージ | 悪意のあるメッセージを要約させる |
| GitHubイシュー | イシューの内容にペイロードを埋め込む |
| ウェブ検索結果 | 検索結果に悪意のあるコンテンツ |
| メール | カスタマーサポートメールを処理 |
開発者が日常的に行う作業が、すべて攻撃ベクトルになり得たのです。
MCPoison: チーム全体の危殆化
関連する脆弱性として、MCPoison（CVE-2025-54136） も発見されました。
MCPoisonの攻撃シナリオ:
- 攻撃者が無害なMCP設定ファイルをリポジトリにコミット
- チームメンバーがそれを一度承認
- 攻撃者が静かに設定を変更（バックドアコマンドを追加）
- チームメンバーがプロジェクトを開くたびにバックドアが実行
一人のチームメンバーの承認が、チーム全体の永続的な危殆化 につながりました。
vibe codingサイトへの攻撃チェーン：数分で完了
AIM Securityの報告によると：
「SNSの投稿からリモートコード実行まで、この攻撃チェーンは数分で完了した」
タイムライン:
- 攻撃者がSlackで悪意のあるメッセージを送信
- 開発者がCursorでそのメッセージを要約
- MCP設定が書き換えられる
- 任意のコマンドが開発者権限で実行
- 完了まで数分
従来のセキュリティ対策（ファイアウォール、アンチウイルス等）では検出困難な攻撃でした。
AI開発ツールの開発者権限の危険性
この攻撃が特に危険だった理由は、開発者権限 での実行でした。
開発者のマシンには:
- ソースコード
- APIキー、シークレット
- データベース接続情報
- クラウドの認証情報
- 本番環境へのアクセス権
開発者のマシンを乗っ取ることは、本番環境への入り口を得る ことと同義です。
対応タイムライン
Cursorチームは迅速に対応しました。
タイムライン:
| 日付 | 出来事 |
|---|---|
| 7月7日 | AIM SecurityがCursorに非公開報告 |
| 7月8日 | パッチがmainブランチにマージ |
| 7月29日 | Cursor 1.3リリース（修正含む） |
| 8月1日 | CVE-2025-54135公開 |
24時間以内 にパッチが作成されたことは評価できます。
修正内容
修正後のCursor（バージョン1.3.9以降）では：
変更点:
- すべてのMCP設定変更に 明示的なユーザー承認 が必要
- Auto-Runモードの無効化オプション
- 不明なソースからのMCPサーバー追加を禁止
推奨される緩和策:
- Cursor 1.3.9以上にアップデート
- Auto-Runモードを無効化
- 不明なソースからのMCPサーバーを禁止
vibe codingツールの信頼性
この事件は、vibe codingツール自体の信頼性について疑問を投げかけました。
問題の構造:
vibe coder
↓
vibe codingツール（Cursor等）を信頼
↓
ツールに脆弱性
↓
開発環境が危殆化
↓
作成したアプリも危殆化vibe coderは、ツールを 無条件に信頼 しています。しかし、そのツール自体に脆弱性があれば、すべてが危険に晒されます。
この事例から学ぶべき教訓
CurXecute事件から学ぶべきことは以下の通りです。
-
開発ツールそのものが攻撃対象になる
- vibe codingツールも例外ではない
-
「拒否」を押しても攻撃が成功することがある
- UIの動作を過信しない
-
外部コンテンツの処理は危険
- Slackメッセージ、イシュー、検索結果
-
チーム共有設定は永続的なリスク
- MCPoisonによるチーム全体の危殆化
-
開発者権限は本番環境への入り口
- 開発環境のセキュリティも重要
-
ツールを常に最新に保つ
- セキュリティアップデートは即時適用
まとめ：重要ポイントの振り返り
- CurXecute（CVE-2025-54135）はCursor IDEのリモートコード実行脆弱性
- 深刻度8.6、Slackメッセージから数分でRCEが可能
- ユーザーが「拒否」を押しても攻撃が成功する可能性
- MCPoison（CVE-2025-54136）でチーム全体が永続的に危殆化
- 開発者権限での実行により、本番環境への入り口に
- 教訓：開発ツールそのものが攻撃対象になる