Cursor CEOが「自社ツールは脆い基盤を作る」と認めた日。ゼロクリック脆弱性CurXecuteが突きつけた、バイブコーディングの次の問い

自社ツールのCEOが「やめとけ」と言う異常事態

前回の記事で、バイブコーディングプラットフォームLovable（ラバブル）のアプリ1,645個から170個の裏口が見つかった話を書きました。「コード生成の品質」に問題があった事件です。

今回はもう1段階、深い話をさせてください。

AIコードエディタCursor（カーソル）のCEO、Michael Truell（マイケル・トゥルエル）氏がFortune誌のインタビューでこう発言しています。

「目を閉じてコードを見ず、AIに脆い基盤の上に建物を作らせる。1階、2階、3階と積み上げていくと、いずれ崩れ始める」

Cursorですよ。バイブコーディングの代名詞的ツールのCEOが、危うさを認めている。日本で100万人が毎日使っているツールの責任者です。「脆い基盤（shaky foundations）」という言葉を選んだ。

この発言はCambridge Today（2026-03-27再掲）で再び注目を集めました。そしてほぼ同時期に、Cursor本体からゼロクリックで遠隔コード実行が可能な脆弱性が見つかった。「CurXecute（カーゼキュート）」、CVE-2025-54135。CVSS（脆弱性の深刻度スコア）は8.6。10点満点中8.6です。

前回の記事は「AIが生成したコードに穴がある」話でした。今回は「AIコーディングツール自体に穴がある」話。攻撃対象がコードからツールに移った。これがバイブコーディング安全論争の第2弾として共有したいことです。

CVE-2025-54135「CurXecute」とは何が起きたのか

技術的な話を噛み砕きますね。

CurXecuteを発見したのはAIM Security（エイムセキュリティ）のリサーチチーム。AIM Securityの詳細レポートによると、攻撃の流れはこうです。

1. 攻撃者が外部のMCPサーバーに悪意あるプロンプトを仕込む
2. Cursorがそのサーバーに接続すると、Agentがプロンプトを読み込む
3. Agentが.cursor/mcp.json（設定ファイル）を書き換える
4. Auto-Runモードが有効だと、書き換えた設定がそのまま実行される
5. 結果、攻撃者が開発者のマシン上で任意のコードを実行できる

MCP（Model Context Protocol）とは、AIエージェントが外部ツールやサービスと連携するための通信規格です。Cursorは外部MCPサーバーを通じて機能を拡張できる仕組みを持っている。その拡張機能の入り口が攻撃の突破口になりました。

「ゼロクリック」の意味

ここが怖いところです。

ユーザーは何もクリックしていない。怪しいリンクを踏んだわけでもありません。ただCursorを使って、MCPサーバーに接続しただけ。Check Point Research（チェックポイントリサーチ）の分析では、この攻撃を”MCPoison”と名付けています。MCPサーバーを「毒入り」にして、接続した開発者のマシンを乗っ取る手法です。

CyberScoop（サイバースクープ）の報道によると、攻撃が成功した場合に可能になることは多岐にわたります。ランサムウェアの設置、データの窃取、AIモデルの操作、バックドアの設置。開発者のマシンはソースコードや認証情報の宝庫なので、企業にとっての被害は計り知れません。

修正はされた。問題はそこじゃない

Cursor側は対応済みです。バージョン1.3.9で修正されており、Auto-Runモードの挙動も改善されている。

とはいえ問題の本質は「パッチが出たかどうか」ではありません。MCPという新しい連携規格が、セキュリティ検証が十分でないまま各ツールに実装されている現状が問題なんです。今日直ったCursorの穴が、明日は別のAIコーディングツールで見つかるかもしれない。

Tenable（テナブル）のFAQページが状況を物語っています。CurXecute（CVE-2025-54135）と同時に、別の脆弱性MCPoison（CVE-2025-54136）も報告された。1つのツールから2つの脆弱性が同時に出てくる。この分野の成熟度がわかるでしょう。

攻撃対象が「コード」から「開発環境」に移った

前回のLovable事件と今回のCurXecute。並べると、攻撃対象の変化が見えてきます。

Lovable（前回）: AIが書いたコードにセキュリティ設定が抜けていた。RLS未設定でデータベースが丸裸。問題はAIの「出力」にあった。

CurXecute（今回）: AIコーディングツール自体が攻撃経路になった。MCP経由でツールが乗っ取られ、開発者のマシン全体が危険に晒された。問題はAIの「インフラ」にある。

CS出身だからこそ感じることがあります。「SaaSのAPIが便利だから使う。でもそのAPIの認証が甘い」。クラウドサービスの黎明期に何度も見た構造と同じです。新しい技術が便利すぎて、セキュリティの検証が追いつかないまま普及してしまう。MCPも今まさにその段階にいます。

Cursor CEO自身が「脆い基盤」と認めたのは、この構造を自覚しているからでしょう。Fortune誌の別記事によると、Cursorは評価額$293億（約4.4兆円）の企業。100万人の日々のユーザーを抱える責任者が「脆い」と言う。これは批判ではなく、当事者としての危機感の表明だと私は読んでいます。

開発者が今週やるべきセキュリティチェック5項目

前回は3項目でしたが、CurXecuteの発覚を受けて2項目追加します。ツール側の設定確認が加わったのが大きな違いです。

チェック1: Cursorのバージョンを確認する

まずこれです。バージョン1.3.9以降であれば、CurXecuteの脆弱性は修正済み。

# Cursorのバージョン確認方法
# メニュー → Help → About でバージョンを確認
# 1.3.9未満なら即アップデート

自動更新を有効にしている人が多いと思いますが、念のため手動で確認してください。1分で終わります。

チェック2: Auto-Runモードの設定を見直す

CurXecuteの攻撃が成立する条件の1つが「Auto-Runモードの有効化」でした。便利な機能ですが、外部MCPサーバーからの指示を無条件で実行してしまうリスクがある。

// .cursor/settings.json の確認ポイント
// Auto-Runが有効になっている場合の設定例
{
  "cursor.agent.autoRun": true  // ← これが攻撃条件の1つ
}
// 信頼できるMCPサーバーだけを明示的に許可する運用を推奨

全オフにする必要はありません。信頼できるMCPサーバーだけをホワイトリストで管理し、未知のサーバーからの自動実行は無効にする。これがバランスの取れた対策です。

チェック3: .cursor/mcp.json を確認する

プロジェクトのルートディレクトリに.cursor/mcp.jsonが存在するか確認してください。自分で作った覚えがないのに存在していたら、要注意。CurXecuteの攻撃手法では、このファイルを新規作成して悪意あるMCPサーバーを登録するからです。

# プロジェクトルートで確認
# 自分で作成した覚えがないmcp.jsonがあれば要注意
ls -la .cursor/mcp.json 2>/dev/null && echo "ファイルあり: 内容を確認してください" || echo "ファイルなし: OK"

チェック4: 前回の3項目を再実行

前回の記事で紹介した3つのチェックも引き続き有効です。

• RLSポリシーの確認: Supabase（スーパベース）を使っているなら、全テーブルのRLS設定を確認
• フロントエンドのAPIキー検索: ブラウザの開発者ツールでsk-、AKIA、AIza等を検索
• AIに攻撃者視点でレビュー依頼: 別セッションで「攻撃者として脆弱性を探して」と依頼

チェック5: MCPサーバーの接続先を棚卸しする

これは新しい観点です。自分のCursorがどのMCPサーバーに接続しているか、把握していますか。

Palo Alto Networks Unit 42（パロアルトネットワークス）のガイドが興味深い指摘をしています。MCPサーバーの接続管理を「バイブコーディングのサプライチェーンセキュリティ」と位置づけた。npmパッケージの依存関係を管理するように、MCPサーバーの接続先も管理すべきだと。

確認すべきは3点。

• 接続中のMCPサーバーは全て自分が意図的に追加したものか
• 各サーバーの提供元は信頼できる組織か
• 使っていないMCPサーバーの接続が残っていないか

“Secure Vibe Coding”という答えが見え始めている

ここまで読んで「怖い話ばかりだ」と思った人もいるかもしれません。とはいえ私はむしろ希望を感じています。

なぜなら「答え」が具体的に見え始めているからです。

Forrester（フォレスター）のブログ記事のタイトルがそのまま答えを示しています。「Secure Vibe Coding: It’s A Paradigm, Not A Paradox」。安全なバイブコーディングはパラドックスではない。パラダイム（新しい常識）だと。

ForresterはAIセキュリティエージェントの台頭を予測しています。セキュリティの専門知識がなくても、AIがコード生成と同時にセキュリティ検証を実行する。後付けの検査ではなく、生成プロセスに組み込まれたセキュリティ。これが“Secure Vibe Coding”の本質です。

英国NCSC（国家サイバーセキュリティセンター）も動いています。バイブコーディングのセキュリティガイドラインを策定中。政府機関が「バイブコーディング」という言葉を使ってガイドラインを出す時代が来ているわけです。

Checkmarx（チェックマークス）のセキュリティガイドでは、実務的なフレームワークとして以下の3層を提案しています。

• 生成時: プロンプトにセキュリティ要件を含める（前回紹介したVibeContractの考え方）
• 検証時: AI生成コードを別のAIで自動レビューする（攻撃者視点レビュー）
• 運用時: 継続的なセキュリティスキャンをCI/CDパイプラインに組み込む

この3層は、前回の記事で紹介した”VibeContract”とも完全に整合します。契約（プロンプト）→検証（レビュー）→監視（スキャン）。バイブコーディングの速さを殺さずに、安全を確保する道筋が見えてきた。

まとめ: CEOの警告を、行動に変える

三部作の第2弾として、伝えたかったことを整理します。

• 何が起きたか: Cursorにゼロクリック遠隔コード実行脆弱性（CurXecute、CVSS 8.6）が発見された。MCP Auto-Start経由で、ユーザーの操作なしに開発者マシンが乗っ取られるリスクがあった
• なぜ重要か: 攻撃対象が「AIが生成したコード」から「AIコーディングツール自体」に移行した。前回のLovable事件とは次元が違う
• Cursor CEOの姿勢: Truell氏自身が「脆い基盤」を認めている。$293億企業の責任者による率直な危機感の表明
• 今週やること: バージョン確認、Auto-Run設定見直し、mcp.json確認、前回の3項目再実行、MCPサーバー棚卸し
• 見えてきた答え: Forrester、NCSC、Checkmarxが“Secure Vibe Coding”のフレームワークを提示し始めている

私は「動けばOK」が信条です。その信条は今も変わりません。一方で「動く環境自体が乗っ取られる」リスクがあるなら、話は別。環境のセキュリティを確認するのは最低限のマナーだと思うんですよね。

かつてプロのエンジニアには敵わないと思った。今もセキュリティの深い設計では敵わないかもしれない。それでもバージョンを確認する、Auto-Runの設定を見直す、MCPサーバーの接続先を棚卸しする。これはプロじゃなくても今日中にできることです。

バイブコーディングの速さは本物の武器。ただし武器を振るう前に、握っている柄が安全かどうかは確認しておきたい。Cursor CEOの警告は、敵ではなく味方からの忠告として受け取るべきだと、私は思っています。

次回（三部作の最終回）では、Forresterが提唱する“Secure Vibe Coding”パラダイムを深掘りします。バイブコーディングの速さとセキュリティを両立させる具体的な設計手順を、一緒に考えていきましょう。