近年、開発現場では生産性向上を目的として、AIを活用したコード補完・自動化ツールの導入が急速に進んでいます。Cursor、Copilot、各種LLMベースのIDEは、もはや一部の先進的なチームだけのものではなく、多くの開発組織にとって日常的なツールとなりました。

しかし、その「便利さ」の裏側で、これまでの開発環境には存在しなかった新しい攻撃面（Attack Surface）が生まれていることをご存じでしょうか。

本ブログでは、AIコードエディタ Cursor において確認された重大な脆弱性
「MCP（Model Context Protocol）設定を悪用した遠隔コード実行（RCE）」
――通称 MCPosion（CVE-2025-54136） について、その仕組み・攻撃フロー・リスク、そして実践的な対策を整理して解説します。

脅威の概要：AIが「信頼した設定」が攻撃の起点になる

今回の脆弱性の本質は、Cursorが採用している「信頼モデル」そのものにあります。

Cursorは、AIが外部ツールを操作するための仕組みとして MCP（Model Context Protocol） を採用しています。
開発者はプロジェクトごとに .cursor/rules/mcp.json を定義し、以下のような情報を記述できます。

  • MCPの名前
  • 実行されるコマンド
  • 引数（パラメータ）

Cursorはプロジェクトを開く際、この .cursor ディレクトリを自動的にスキャンし、定義されたMCPを処理します。

問題はここからです。

一度ユーザーが 「このMCPは信頼する」 と承認すると、
以降は “名前” だけを基準に信頼判定が行われ、実行コマンドや引数の変更は再確認されません。

この挙動を悪用することで、
後から悪意あるコマンドに差し替えても、追加の承認なしで実行される
という深刻な状態が生まれます。

攻撃フロー：GitHub上の「普通のコラボレーション」が罠になる

MCPosion攻撃は、非常に現実的かつ静かに進行します。
特別な脆弱なサーバーや公開サービスは必要ありません。

攻撃の流れは、以下の4段階です。

1. 初期侵入：一見無害なコミット

攻撃者は、共有GitHubリポジトリに対して
一見すると問題のないMCP設定を含むコミット を行います。

  • 悪意のあるコマンドは含まない
  • 通常のツール定義に見える
  • レビュー時に疑われにくい

この段階では、被害はまだ発生しません。

2. Cursorでのプロジェクト承認

被害者（開発者）がCursorでプロジェクトを開くと、
新しいMCPに対する 「実行を許可しますか？」 という確認ダイアログが表示されます。

ここでユーザーが承認すると、
その MCP名は「信頼済み」状態 として記録されます。

3. 悪性ペイロードの挿入

攻撃者は次のコミットで、
すでに信頼されたMCPの「実行コマンド」や「引数」だけを差し替えます。

  • MCP名は変更しない
  • しかし実行内容は完全に別物
  • Cursorは再承認を求めない

これが、この脆弱性の核心です。

4. Exploit実行：同期・再起動だけでRCE

被害者が以下のいずれかを行った瞬間、攻撃は成立します。

  • リポジトリを同期（pull）
  • Cursorを再起動

結果として、
悪意あるコマンドがユーザー権限で即座に実行 されます。

研究では、Reverse Shellを用いた 完全なシステム掌握 も確認されています。

なぜ危険なのか：従来のセキュリティ前提が崩れる

この問題が深刻なのは、単なる「ツールのバグ」ではない点です。

従来の前提

  • GitHubリポジトリはレビューされる
  • ローカルで実行されるコードは自己責任
  • IDEは「受動的なツール」

MCPosionが突きつけた現実

  • 設定ファイルが実行主体になる
  • AIが自動でコマンドを実行する
  • 「一度の信頼」が将来の変更まで許可してしまう

つまり、
AI支援開発環境そのものが攻撃経路になる
という、新しい脅威モデルが露呈したのです。

検出の難しさ：ログもアラートも残らない

この攻撃は以下の理由で非常に検知が困難です。

  • 正規のGitHub操作（commit / pull）
  • 正規のCursor動作
  • ユーザー自身が承認したMCP

EDRやアンチウイルスから見ても、
「開発者がツールを使っただけ」に見えるケースがほとんどです。

対策：AI開発環境を“信頼しすぎない”

1. Cursorのアップデート（最優先）

本脆弱性は 最新バージョンで修正済み です。
Cursorを使用している環境では、速やかなアップデートを強く推奨します。

2. MCP設定のコードレビュー対象化

  • .cursor/ 配下を 通常のコードと同等にレビュー
  • MCPの「名前」だけでなく
    実行コマンド・引数の差分確認を必須化

3. AIツールの権限を最小化

  • 開発用端末での管理者権限使用を避ける
  • AIツール経由で実行されるコマンドの影響範囲を限定

4. 「信頼」の再定義

  • 一度の承認＝永続的信頼、という設計を前提にしない
  • チーム内で AIツール利用ポリシー を明文化

結論：AIは強力だが、中立ではない

MCPosionは、
「AIを使うこと自体が危険」という話ではありません。

問題は、
人間が築いてきた“信頼の境界”を、AI時代のワークフローにそのまま持ち込んでしまったこと にあります。

AIはコードを書き、
AIはツールを動かし、
AIは設定を解釈し、
そして――AIは攻撃経路にもなり得る。

今こそ、
「AIが何を、どこまで、誰の権限で実行できるのか」
を改めて問い直す時です。

開発効率とセキュリティはトレードオフではありません。
正しく設計すれば、両立できます。

本ブログが、皆さまのAI開発環境を見直すきっかけになれば幸いです。

これまで、Colorkrew Securityのユンジェホがお届けしました。
ありがとうございました。