Cursor IDEに、プロンプトインジェクションだけでOS全体の任意コード実行（RCE）に到達する深刻な脆弱性が公表された。Cato Networks（Cato AI Labs）が発見したCVE-2026-50548とCVE-2026-50549は、まとめて「DuneSlide」と名付けられ、いずれもCVSS 9.8（Critical）。ユーザーの承認クリックを一切必要としない「ゼロクリック」攻撃で、MCPサーバーの応答やWeb検索結果に仕込まれた悪性の指示だけでCursorのサンドボックスが破られる。影響を受けるのはCursor 3.0未満の全バージョンで、2026年4月2日リリースのCursor 3.0で修正済みだ。

サプライチェーン攻撃全体の手法・防御ツールを体系的に押さえたい場合は、ピラー記事サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストを先に読むと、本CVEの位置付けが掴みやすい。本記事はその中でも「DuneSlideという具体的な脆弱性に、開発者とセキュリティチームがどう備えるか」に絞って掘り下げる。

この記事のポイント
  • ・DuneSlideはCVE-2026-50548（working_directoryパラメータの未検証な許可リスト追加）とCVE-2026-50549（symlinkパス正規化失敗時のフォールバック欠陥）の2件。いずれもCVSS 9.8 Critical。
  • ・両CVEとも最終的にcursorsandboxバイナリの上書きに到達し、サンドボックスそのものを無効化する。以降のコマンドはOS全体で無制限に実行される。
  • ・攻撃はMCPサーバー応答やWeb検索結果へのプロンプトインジェクションのみで成立し、ユーザー操作は不要（ゼロクリック）。
  • ・Cursor 3.0（2026年4月2日リリース）で修正済み。対応はcursor --versionでのバージョン確認とアップデートが最優先。
timeline title DuneSlide 発見から公開までのタイムライン 2026-02-19 : Cato AI Labsが2件の脆弱性をCursorへ報告 2026-02-23 : Cursorが初期段階で却下
（MCPサーバー悪用を脅威モデル外と判断） 2026-02-26 : Catoがセキュリティチームへ直接エスカレーション 2026-04-01 : CVE-2026-50548の修正を確認 2026-04-02 : Cursor 3.0リリース 2026-06-01 : CVE-2026-50549の修正を確認 2026-06-05 : 両CVE番号が正式採番 2026-07 : Cato Networksが技術詳細を公開
SecurityWeek・The Hacker News・CSO Onlineが後追い報道

本記事はこのあと、①時系列の詳細、②DuneSlideの技術的な仕組み、③なぜゼロクリックが成立するか、④既出CVE-2026-26268との違い、⑤対策手順、⑥自システムで確認する4つのコマンド、⑦影響範囲マトリクス、⑧他のAI IDE/CLIへの示唆——の順に進む。今すぐ手を動かしたい場合は「自システムで確認する4つのコマンド」から読み、cursor --versionの結果次第で対策セクションへ進む、という使い方でも構わない。

時系列：発見から公開までの5ヶ月

DuneSlideは一度に公表されたわけではない。Cato AI Labsの報告からCVE番号の採番、技術詳細の公開まで、約5ヶ月のプロセスを経ている。

日付 出来事
2026年2月19日 Cato AI Labsが2件の脆弱性をCursorへ報告
2026年2月23日 Cursorが初回却下（MCPサーバー悪用を脅威モデルに含めていなかった）
2026年2月26日 Catoがセキュリティチームへ直接エスカレーション、再調査開始
2026年4月1日 CVE-2026-50548の修正が確認される
2026年4月2日 Cursor 3.0リリース（両脆弱性の修正を含む）
2026年6月1日 CVE-2026-50549の修正が確認される
2026年6月5日 CVE-2026-50548・CVE-2026-50549のCVE IDが正式採番
2026年7月 Cato Networksが「DuneSlide」として技術ブログを公開。SecurityWeek・The Hacker News・CSO Onlineが後追い報道

注目すべきは2026年2月23日の「初回却下」だ。Catoの報告に対し、Cursorは当初「MCPサーバーからの悪性応答」という攻撃経路を脅威モデルに含めていなかったと見られる。AIエージェントが外部ツール（MCPサーバー）やWeb検索結果を「信頼できる入力」として扱う設計上の前提が、この時点でまだ十分に見直されていなかったことを示唆する。Catoが直接セキュリティチームへエスカレーションしたことで再調査が始まり、最終的に2件とも修正に至っている。

CVE-2026-50548の修正確認からCursor 3.0リリースまではわずか1日で、パッチはリリースに間に合わせる形で急がれたとみられる。一方でCVE-2026-50549の修正確認は3.0リリースの約2ヶ月後（6月1日）であり、Cato側の追加検証または段階的な修正が行われた可能性がある。CVE番号の採番自体は両脆弱性まとめて6月5日に行われ、技術詳細の一般公開はさらに1ヶ月以上あとの7月にずれ込んだ。この間隔は、責任ある開示（coordinated disclosure）の一般的な運用に沿ったもので、修正版が十分に行き渡ってから詳細を公開するという考え方がベースにある。

何が起きたか：DuneSlideの技術的な仕組み

プロンプトインジェクション注入からworking_directory操作またはsymlink作成、cursorsandboxバイナリの上書き、OS全体での任意コード実行に至る4段階の攻撃チェーン
DuneSlideの攻撃チェーン。2つのCVEは異なる経路を通るが、同じ「cursorsandbox上書き」に収束する。

DuneSlideという名前は2件の脆弱性の総称で、攻撃の最終地点が同じという共通項を持つ。それぞれの技術的な仕組みを見ていく。

CVE-2026-50548：working_directoryパラメータの未検証な許可リスト追加

CursorのAIエージェントがターミナルコマンドを実行するツール（run_terminal_cmd相当）は、実行ディレクトリを指定するworking_directoryパラメータを持つ。このパラメータがプログラム的に検証されないままサンドボックスの許可リストに追加されてしまう欠陥がCVE-2026-50548だ。NVDの脆弱性種別はCWE-22（パストラバーサル）に分類されている。

プロンプトインジェクションによって攻撃者はこのパラメータを操作し、プロジェクトディレクトリの外にあるパスを許可リストに載せさせられる。SecurityWeekおよびCato Networksの報道によれば、macOSの場合Cursorのサンドボックス制御バイナリは/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandboxに存在する。このパスへの書き込みが許可リストに紛れ込むと、エージェントはこのバイナリ自体を上書きできてしまう。

CVE-2026-50549：symlinkパス正規化の失敗によるフォールバック

CVE-2026-50549は経路が異なる。Cursorのファイルパス解決ロジックにはエッジケースが存在し、シンボリックリンク（symlink）の正規化に失敗した場合、境界チェックを回避して「元のシンボリックリンクパス」へフォールバックしてしまう欠陥がある。NVDの脆弱性種別はCWE-59（ファイルアクセス前のリンク解決不適切）。NVDの説明文では「書き込み前にターゲットパスを正規化してワークスペース内に留まることを確認するが、正規化に失敗すると元のパスへフォールバックし、承認なしで書き込む」と記載されている。

攻撃者はプロジェクトディレクトリの内側に、外部の場所を指すsymlinkを作成する。本来であればCursorはsymlinkの実体（リンク先）を解決し、それがプロジェクト境界の外であれば書き込みを拒否すべきだ。しかし正規化が失敗するケースでは、「symlinkのパス自体はプロジェクト内に見える」という表面上の情報を信用してしまい、out-of-bounds write（境界外書き込み）の保護をすり抜ける。

2つの経路が合流する場所：cursorsandboxの上書き

CVE-2026-50548・CVE-2026-50549のいずれか（あるいは両方の組合せ）を使うことで、攻撃者はサンドボックスの制御を担うcursorsandboxバイナリ、またはシェル設定ファイルを書き換えられる。cursorsandboxが改ざんされると、その後にエージェントが実行するコマンドはサンドボックスの制限を受けずOSレベルで実行される。ここが「サンドボックス化されたはずのコマンド実行」が「非サンドボックスのRCE」へ転換する瞬間だ。

攻撃の一連の流れをシーケンスで整理すると次のようになる。

sequenceDiagram participant Src as 悪性コンテンツ
（MCPサーバー応答/Web検索結果） participant Agent as Cursor AIエージェント participant Sandbox as cursorsandbox participant OS as OS（ホスト環境） Src->>Agent: プロンプトインジェクションされた指示 Note over Agent: working_directory操作 or
symlink経由の境界外書き込み Agent->>Sandbox: cursorsandboxバイナリを上書き Note over Sandbox: サンドボックス制御が無効化 Agent->>OS: 以降のコマンドを非サンドボックスで実行 OS-->>Agent: 任意コード実行が成立（RCE）

なぜ「ゼロクリック」なのか：プロンプトインジェクションの経路

DuneSlideがとりわけ深刻とされるのは、攻撃成立にユーザーの明示的な操作を必要としない点にある。従来のフィッシングやマルウェア配布は、悪性リンクのクリックや添付ファイルの実行といった「被害者の一手間」を前提にすることが多い。DuneSlideはその前提を必要としない。

攻撃者が悪性の指示を仕込める場所は主に2つ報告されている。

MCPサーバーの応答またはWeb検索結果に指示が混入し、エージェントが正規業務として読み込み、クリック不要で実行に至る経路
どちらの経路も「情報取得」という正規業務に見えるため、ユーザーが警戒するタイミングがない。

・MCPサーバーの応答：ユーザーが接続したMCP（Model Context Protocol）サーバーが返すレスポンス内容に、Cursorのエージェント宛ての指示を紛れ込ませる。ユーザーは「いつも通りMCPツールを呼び出しただけ」のつもりでも、応答本文に埋め込まれた指示がエージェントに読み込まれ実行される
・Web検索結果：エージェントがWeb検索を行い、その結果ページの内容を要約・参照する過程で、ページ内に仕込まれた指示がプロンプトインジェクションとして機能する

どちらの経路も、エージェントが「情報を取得する」という正規の業務を行っているだけに見える。ユーザーが警戒するタイミングが存在しない。これはCVE-2026-26268（後述）のような「リポジトリをクローンしてGit操作を頼む」という比較的分かりやすいトリガーとは異なり、日常的なMCP利用・Web検索利用そのものが攻撃面になるという点で、防御側の対応がより難しい。

「MCPサーバーは自分で選んだから安全」という思い込みに注意
DuneSlideの攻撃面は、悪意あるMCPサーバーに直接接続するケースだけではない。正規のMCPサーバーが第三者データ（Webページ・APIレスポンス等）を中継し、その中に埋め込まれた指示がそのままエージェントに渡ることでも成立し得る。MCPサーバーの実装者自身が悪意を持たなくても、上流のデータソースが汚染されていれば同じ経路が使われる可能性がある。

CVE-2026-26268（Gitフック経由RCE）との違い

Cursor IDEでは本記事のDuneSlide以前にも、CVE-2026-26268というサンドボックス脱出型の脆弱性が報告されている。同じ「Cursor」「サンドボックス脱出」というキーワードで混同されやすいが、攻撃の起点と経路は別物だ。

CVE-2026-26268は悪性リポジトリのクローンとGit操作が起点で保護不備のgitフックへの書込みが経路、DuneSlideはMCP応答やWeb検索結果への注入が起点でworking_directory操作やsymlink悪用が経路という比較
起点も経路も異なるが、いずれもCursor 3.0以降で修正済み。
観点 CVE-2026-26268（Gitフック経由） DuneSlide（CVE-2026-50548/50549）
攻撃の起点 悪性リポジトリのクローン＋Git操作 MCPサーバー応答／Web検索結果への注入
ユーザー操作 リポジトリをクローンしてAgentに作業依頼 不要（ゼロクリック）
脆弱性の核心 保護不備の.git設定（gitフック）への書き込み working_directory未検証／symlink正規化失敗
最終到達点 フック発火によるサンドボックス外コード実行 cursorsandboxバイナリの上書きによる無効化
CVSS 9.9（NVD）／8.0（GitHub CNA） 9.8（両CVEとも）
修正バージョン Cursor 2.5 Cursor 3.0
発見者 Novee（Assaf Levkovich氏） Cato Networks（Cato AI Labs）

両者に共通するのは、「AIエージェントの自律実行」が既存のセキュリティ境界（Gitフックの信頼、パス検証）をすり抜ける通り道になっている点だ。個別の脆弱性としては別物だが、根本にある構造的リスクは同じ系譜にある。エージェントが外部入力を信頼しすぎる設計が、形を変えて2度露呈した格好だ。両CVEともCursor 3.0以降では修正済みのため、最新版へのアップデートが両方の対策を兼ねる。

対策：緊急・推奨・長期

Cursor 3.0未満は working_directory が未検証のまま許可リストに追加され symlink 正規化失敗時に元のパスへフォールバックする一方、Cursor 3.0以降は境界検証が強化されている比較
DuneSlideの対応は「アップデートのみ」。設定変更での回避策は公式には存在しない。

緊急（今日中）

・Cursorを3.0以降にアップデート：メニュー → Cursor → Check for Updates、または自動アップデートを有効化。DuneSlideの根本原因はコード側の欠陥であり、設定変更による回避策はない
・自動ターミナル実行の設定を見直す：エージェントが承認なしでコマンドを実行できる設定（自動実行・auto-run系）を一時的に無効化し、コマンドごとの確認を挟む
・接続中のMCPサーバーを棚卸し：信頼できない、または出所不明なMCPサーバーが登録されていないか確認し、不要なものは削除する

推奨（今週中）

・working_directoryを伴うコマンド実行の承認を必須化：可能であれば、プロジェクト外のパスを指定するコマンド実行には都度の目視承認を挟む運用にする
・クローン・展開したプロジェクト内のsymlinkを点検：見慣れないsymlinkがプロジェクトディレクトリ内に存在しないか確認する。特に外部から取得したテンプレートやサンプルコードでは注意
・Web検索結果を要約させるタスクでの警戒：エージェントに「このページの内容に従って作業して」といった曖昧な指示を与えず、要約結果は人間が確認してから次のアクションに進める

長期（恒久対策）

第1層は即時アップデートでcursor --versionにより3.0以降を確認、第2層は自律実行の制限で自動ターミナル実行・MCP自動承認を見直す、第3層は実行環境の隔離で信頼できないリポジトリをコンテナ/VMで開く3層防御
1層が破られても次の層で止める、3層防御の考え方。

・信頼できないリポジトリ・MCPサーバーでの作業をコンテナ／VMで隔離：ホスト側のSSHキー・クラウドクレデンシャルを持ち込まない構成にすることで、万一サンドボックスが破られても被害範囲を局所化できる
・AIエージェントのツール呼び出しログを監査対象にする：working_directoryの変更やファイル書き込み先が想定外のパスになっていないか、定期的にログを確認する運用を組み込む
・MCPサーバー・Web検索結果を「信頼できない入力」として扱うポリシーを社内で明文化：プロンプトインジェクションへの一般的な防御原則を、CursorだけでなくAIエージェント全般の運用ルールに反映する

自システムで確認する4つのコマンド

ここが本記事の実務パートだ。DuneSlideの実際の攻撃ペイロードはCato Networksから公開されていない（責任ある開示の流儀として妥当な判断）ため、攻撃の再現ではなく自分の環境がリスク帯にあるかどうかを点検するコマンドを4つ示す。いずれも自分が管理するマシンに対して実行する、読み取り中心の確認作業だ。

① Cursorのバージョンを確認する

最優先の確認。3.0未満であれば両CVEの影響を受ける。

# CLIが導入済みの場合
cursor --version

# CLIが無い場合はアプリ内で確認
# メニュー → Cursor → About Cursor

3.0未満のバージョン番号が表示された場合、即座にアップデートする。

② 自動ターミナル実行・MCP自動承認の設定を確認する

エージェントがユーザー承認なしでコマンドを実行できる設定になっていないかを見る。

# macOS: Cursorの設定ファイルからauto-run系の項目を確認
grep -riE "auto.?run|autoApprove|yolo" ~/Library/Application\ Support/Cursor/User/settings.json 2>/dev/null

# Linux
grep -riE "auto.?run|autoApprove|yolo" ~/.config/Cursor/User/settings.json 2>/dev/null

該当項目が有効になっている場合、必要性を再検討し、不要であれば無効化してコマンドごとの承認に戻す。

③ 接続中のMCPサーバー一覧を棚卸しする

信頼できないMCPサーバーが登録されていないかを確認する。

# MCPサーバー定義ファイルを確認（環境変数にAPIキー等が平文で入っていないかも合わせて確認）
cat ~/.cursor/mcp.json 2>/dev/null
cat .cursor/mcp.json 2>/dev/null   # プロジェクト単位の設定

出所が不明なサーバーや、更新の追跡が難しいサードパーティ製サーバーは、必要性を精査したうえで削除を検討する。

④ プロジェクト内の不審なsymlinkを検出する

CVE-2026-50549の経路を踏まえ、プロジェクトディレクトリ内に外部を指すsymlinkが無いかを確認する。

# カレントディレクトリ配下のsymlinkとリンク先を一覧表示
find . -type l -exec ls -l {} \; 2>/dev/null

# プロジェクト外（親ディレクトリより上）を指すsymlinkだけを抽出したい場合
find . -type l -exec sh -c 'readlink -f "$1" | grep -qv "^$(pwd)" && echo "$1 -> $(readlink -f "$1")"' _ {} \; 2>/dev/null

見慣れないsymlink、特に外部から取得したテンプレートやサンプルリポジトリに含まれるものは、内容を確認してから作業を進める。

影響範囲マトリクス

自分の構成がどのリスク帯に該当するかを、バージョン×運用設定で整理する。

Cursor 3.0以降かつ自動実行なし・未知MCP接続なしは低リスク、3.0未満かつ自動実行あり・未知MCP接続ありは致命的というバージョンと運用設定によるリスク帯の4段階マトリクス
3.0未満・自動実行あり・未知MCP接続ありの3条件が揃うと、ゼロクリック攻撃の成立条件を満たす。
Cursorバージョン 自動ターミナル実行 未知のMCPサーバー接続 リスク帯
3.0以降 無効 なし 低（修正済み＋慎重運用）
3.0以降 有効 あり 中（脆弱性は修正済みだが運用面のリスクは残る）
3.0未満 無効 なし 中〜高（脆弱だが攻撃面は限定的）
3.0未満 有効 あり 致命的（DuneSlideの主標的構成）

判定軸はシンプルだ。「3.0未満」かつ「自動ターミナル実行が有効」かつ「未知のMCPサーバーに接続している」という3条件が揃うと、ゼロクリックでの攻撃成立条件をすべて満たす。表の下段ほど危険度が上がり、対処の優先順位も下段から着手すべきだ。3.0以降であればコード側の脆弱性そのものは解消されているが、自動実行や未知のMCPサーバー接続といった運用面のリスクは別問題として残る点に注意したい。

他のAI IDE・CLIへの示唆

DuneSlideはCursor固有の実装バグが直接の原因だが、「AIエージェントがMCPサーバー応答やWeb検索結果を信頼できる入力として扱う」という設計上の前提は、多くのAI開発ツールが共有している。各ツールのサンドボックス設計・承認モードを俯瞰しておく。

ツール サンドボックス機構 MCP/外部入力の扱い 参考
Cursor 独自サンドボックス（cursorsandbox） working_directory・symlink検証が3.0で強化 本記事
Claude Code PreToolUseフックで制御可能 フックでBash/ツール呼び出しを業務ポリシーで制限可 フック設定次第で緩和可能
OpenAI Codex CLI 承認モード（read-only/approval-required/auto） モード選択でリスクを調整 read-only優先が無難
Gemini CLI 別途CVSS 10.0のRCEが過去に公開 外部入力の扱いは継続的な要注意分野 ベンダー情報を随時確認

共通して言えるのは、「AIエージェントが自律的に外部ツールを呼び出し、その応答を次の行動判断に使う」構造を持つ製品では、DuneSlideと同種の脆弱性が構造的に起こり得るという前提で運用することだ。1製品のアップデートだけに満足せず、利用しているすべてのAIエージェント系ツールで承認モード・サンドボックス設定を定期的に見直す必要がある。エージェントの過剰権限が招いた別の実害としては、Cursor + Claude AgentがPocketOSで本番DBを9秒で削除した事件も参考になる。プロンプトインジェクション自体の防御原則はGitHubコメント経由のプロンプトインジェクション攻撃解説にも詳しい。

まとめ：ゼロクリックRCEは「AIエージェントが読むものすべて」を攻撃面に変える

DuneSlide（CVE-2026-50548／CVE-2026-50549）が示したのは、working_directoryパラメータの未検証な扱いとsymlinkパス正規化の欠陥という、個別には「よくある実装バグ」に分類され得る問題が、AIエージェントの自律実行という文脈を経由するとユーザー操作ゼロでOS全体のRCEに到達するという現実だ。攻撃者はリンクをクリックさせる必要も、悪性ファイルを実行させる必要もない。MCPサーバーの応答かWeb検索結果に指示を仕込むだけでいい。

対応そのものはシンプルで、Cursorを3.0以降にアップデートすることに尽きる。ただし根本にある「AIエージェントが外部入力をどこまで信頼するか」という設計課題は、DuneSlideの修正だけで解消するものではない。自動実行設定の見直し、MCPサーバーの棚卸し、信頼できない環境での作業のコンテナ隔離——これらを個人・チームの標準運用に組み込んでおくことが、次に同種の脆弱性が公表されたときの被害を左右する。

参照ソース