はじめに
2026年6月、AIコーディングIDE「Cursor」に2件のクリティカル脆弱性「DuneSlide」(CVE-2026-50548 / CVE-2026-50549)へのCVE番号が正式に割り当てられました。CVSSスコアはいずれも 9.8/10(CVSS 3.1)。プロンプトインジェクションだけでサンドボックスを脱獄し、開発者のマシン上で任意コードを実行できるというものです1。
修正自体は2026年4月2日リリースの Cursor 3.0 で完了済みです。しかし、脆弱性を発見した Cato AI Labs のタイムラインを読むと、原因は驚くほどシンプルな設定ミス1つに集約されます。本記事では、この脆弱性の仕組みを技術的に読み解き、Cursorに限らずAIコーディングエージェント全般に応用できる自衛策を、実際に手を動かして確認できる形でまとめます。
この記事で学べること
- DuneSlide(CVE-2026-50548 / CVE-2026-50549)の攻撃の仕組み
- 自分の環境が影響を受けるかを確認するチェックスクリプト
- AIコーディングエージェントのサンドボックスを堅牢にする設定チェックリスト
対象読者
- Cursor / Claude Code / Windsurf などAIコーディングエージェントを業務利用しているエンジニア
- MCP(Model Context Protocol)連携を導入・検討しているチーム
- プロンプトインジェクション対策に関心があるセキュリティ担当者
前提知識
- ターミナルコマンドの基本操作
- サンドボックス・環境変数・シンボリックリンクの基礎知識
TL;DR
- CursorのAIエージェントがコマンドを実行する際、
working_directoryパラメータの検証漏れとシンボリックリンク解決の実装ミスにより、サンドボックス自体のバイナリを書き換えて脱獄できる 脆弱性が見つかった - 攻撃者はユーザーに直接触れる必要がなく、MCP経由で読み込ませた文書やWeb検索結果に指示を仕込むだけ で発火する(ゼロクリック)
- Cursor 3.0(2026年4月2日)以降は修正済み。まずは自分のバージョンを確認し、古ければ即アップデートする
背景: なぜCursorが狙われるのか
Cursorは公式サイトで「Fortune 500企業の64%が導入」と公表している、AIコーディングエージェント市場で存在感の大きいIDEです2。開発者の代わりにターミナルコマンドを実行し、ファイルを編集し、Gitを操作する権限を持つため、攻撃者から見れば「1つ攻略すれば大量の開発機に到達できる」極めて価値の高い標的 になります。
セキュリティ企業 Cato Networks の専門組織 Cato AI Labs は、2026年2月19日にこの脆弱性をCursorへ報告しました。当初はCursor側の脅威モデルが「MCPサーバーの悪用」を想定していなかったため一度却下されましたが、2月26日にエスカレーションした結果、正式に再調査が始まりました3。4月1日に修正がCursor 3.0へ搭載されることが確定し、6月5日に CVE-2026-50548 / CVE-2026-50549 としてCVE番号が正式割当されています。
DuneSlideの仕組み: 2つのCVEを技術的に読み解く
DuneSlideは2つの独立したバグの組み合わせです。どちらも「サンドボックスの外に書き込みができてしまう」という結果は同じですが、突破口が異なります。
CVE-2026-50548: working_directoryパラメータの悪用
Cursorのエージェントがターミナルコマンドを実行する run_terminal_cmd ツールには、任意の作業フォルダを指定できる working_directory というオプションパラメータがあります4。
本来サンドボックスは「コマンドの作業フォルダへの書き込み」を許可する設計でした。ここに落とし穴があります。プロンプトインジェクションによってエージェントに working_directory をプロジェクト外のシステムパスに設定させると、Cursorはそのパスを そのまま書き込み許可リストに追加してしまう のです5。
結果として、攻撃者はサンドボックスヘルパー本体(macOSでは cursorsandbox バイナリ)を上書きし、以降のすべてのコマンドをサンドボックス保護なしで実行できるようになります。
CVE-2026-50549: シンボリックリンク解決のフォールバック不備
もう一方は安全性チェックの回避です。Cursorはファイル書き込み前に、対象パスがシンボリックリンクであれば実体を解決し、実際の書き込み先がプロジェクト内に収まっているかを確認します。
問題は その確認処理が失敗したときのフォールバック にありました。対象が存在しない、または途中のディレクトリに読み取り権限がないなどの理由で解決に失敗すると、Cursorは「安全側に倒して拒否する」のではなく、シンボリックリンク自身のプロジェクト内パスをそのまま信用してしまう 設計になっていたのです6。攻撃者はプロジェクト内に一見無害なシンボリックリンクを仕込み、実体をプロジェクト外の危険なファイルに向けることでこの検証をすり抜けられます。
攻撃者はキーボードに触れなくていい
どちらのCVEも起点はプロンプトインジェクションです。攻撃者はユーザーのCursorに直接コマンドを打ち込む必要がありません。ユーザーがエージェントに読み込ませる MCP経由の外部データやWeb検索結果に悪意ある指示を仕込んでおくだけ で、エージェントがその指示を「ユーザーの意図」と誤認して実行してしまいます1。
自分の環境が影響を受けるか確認する
まずは手元のCursorバージョンを確認します。3.0未満であれば両CVEの影響を受けます。
# macOS / Linux: CLIバージョン確認
cursor --version
# バージョン比較(3.0未満なら警告)
CURSOR_VERSION=$(cursor --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+(\.[0-9]+)?' | head -1)
if [ -n "$CURSOR_VERSION" ]; then
MAJOR=$(echo "$CURSOR_VERSION" | cut -d. -f1)
MINOR=$(echo "$CURSOR_VERSION" | cut -d. -f2)
if [ "$MAJOR" -lt 3 ]; then
echo "⚠️ Cursor $CURSOR_VERSION は DuneSlide (CVE-2026-50548/50549) の影響範囲です。3.0以降へ更新してください"
else
echo "✅ Cursor $CURSOR_VERSION はDuneSlide修正済みバージョンです"
fi
else
echo "cursor CLIが見つかりません。GUIの Cursor > About から手動確認してください"
fi
チーム開発では、CI等で以下のようにチーム全員のバージョンをまとめて棚卸しするのも有効です。
# 例: 社内で配布しているマシン一覧に対してSSH経由でバージョンを収集する
for host in $(cat hosts.txt); do
echo -n "$host: "
ssh "$host" "cursor --version 2>/dev/null || echo 'not found'"
done
対策チェックリスト: パッチ適用だけで終わらせない
Cursor 3.0への更新は必須の前提ですが、DuneSlideの根本原因(プロンプトインジェクション経由でエージェントに任意の操作をさせられる)は今後も別の形で再発しうる、というのが業界の共通認識です7。以下は更新後も継続すべき運用面の対策です。
| # | 対策 | 具体的な設定 |
|---|---|---|
| 1 | バージョン管理 | Cursorを3.0以降に固定し、社内配布用のイメージ/インストーラを更新する |
| 2 | 最小権限化 | エージェントのファイルシステムアクセスを作業フォルダのみに制限する |
| 3 | 承認フローの必須化 | Auto-Runモードを無効化するか、コマンド実行前の人間承認を必須にする |
| 4 | MCP接続の絞り込み | 任意のWebコンテンツ自動取得を避け、許可リスト化した固定のMCPサーバーのみ接続する |
| 5 | 環境変数の隔離 | 認証情報を環境変数に直接置かず、シークレットマネージャー経由で注入する |
| 6 | 監査ログ | エージェントの実行ログを有効化し、想定外のGit操作やファイル書き込みを検知できるようにする |
特に4番目の「MCP接続の絞り込み」は、DuneSlideの侵入経路そのものを塞ぐ対策です。エージェントが読みに行く先が固定・信頼済みのMCPサーバーだけであれば、外部コンテンツ経由のプロンプトインジェクションの機会自体が大きく減ります。
Auto-RunモードとAllowlistの組み合わせにも別のCVE-2026-22708(シェルビルトインバイパス、Cursor 2.3で修正済み)が存在します。
exportやcdのようなシェル組み込みコマンドはコマンド許可リストの監視対象外になりやすいため、Allowlistだけに頼った運用は避けてください8。
著者視点の発見ポイント
DuneSlideの2つのCVEを読み比べて筆者が着目したのは、どちらも「サンドボックスの脱獄」ではなく「サンドボックスに書き込んでいい場所の判定ミス」 だという点です。サンドボックスの実装自体は堅牢でも、「どこまでを信頼するか」を決めるパラメータ(working_directory)や、判定に失敗したときのフォールバック挙動(symlink解決失敗時の扱い)にバグが仕込まれると、防御機構ごと無力化されてしまいます。
これはCursorに限った話ではありません。Claude Code・Windsurf・その他のAIコーディングエージェントも、ユーザーの代わりにコマンドを実行する以上、同種の「境界判定ロジック」を必ず持っています。DuneSlideから得られる教訓は、エージェントのサンドボックス実装を評価するときは『通常時の動作』だけでなく『検証に失敗したときにどちら側へフォールバックするか』を必ず確認する、という視点です。安全側フォールバック(deny by default)になっているかを、自分たちが使うツールでも一度確認してみることをお勧めします。
まとめ
- DuneSlide(CVE-2026-50548 / CVE-2026-50549)はCVSS 9.8のクリティカル脆弱性で、Cursor 3.0未満のすべてのバージョンが影響を受ける
- 攻撃はプロンプトインジェクション起点のゼロクリックで、
working_directoryパラメータとシンボリックリンク解決のフォールバック不備という2つの実装ミスが原因だった - パッチ適用(Cursor 3.0以降)に加えて、MCP接続の絞り込み・最小権限化・承認フローの必須化を運用ルールとして組み込むことが重要
- AIコーディングエージェントを評価する際は「検証失敗時にどちらへフォールバックするか」を必ずチェックする
参考リンク
- DuneSlide: Two Critical RCE vulnerabilities | Cato Networks — 発見元による技術解説・開示タイムライン
- Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox and Run Commands | The Hacker News — CVE番号・開示タイムラインの詳細
- Sandbox bypass flaws in Cursor IDE highlight prompt injection as an RCE vector | CSO Online — working_directory・symlink双方の技術詳細
- CVE-2026-22708 | SentinelOne Vulnerability Database — 関連するシェルビルトインバイパス(CVE-2026-22708)の詳細
- Cursor for Enterprise — Fortune 500企業64%導入の一次情報
-
Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox and Run Commands | The Hacker News(2026年7月1日公開) ↩ ↩2
-
Cursor for Enterprise — 「Trusted by 64% of Fortune 500 companies」 ↩
-
DuneSlide: Two Critical RCE vulnerabilities | Cato Networks — 開示タイムライン(2月19日報告・2月23日却下・2月26日エスカレーション・4月2日Cursor 3.0で修正・6月5日CVE割当) ↩
-
Sandbox bypass flaws in Cursor IDE highlight prompt injection as an RCE vector | CSO Online ↩
-
同上。working_directoryパラメータが書き込み許可リストへ無条件追加される挙動について ↩
-
同上。シンボリックリンク解決失敗時のフォールバック挙動について ↩
-
Critical Cursor AI Code Editor Flaws Could Lead to OS-Level Remote Code Execution | SecurityWeek ↩
-
CVE-2026-22708 | SentinelOne Vulnerability Database — CVSS 7.2、Cursor 2.3で修正済み ↩