Cursor AIに脆弱性チェーン「NomShub」、悪意あるリポジトリを開くだけで開発端末が乗っ取り

「AIコーディングツールって便利だけど、セキュリティ的に安全なの？」
「Cursorでリポジトリを開くだけで乗っ取られるって本当？」

チップス

ボス！
Cursor AIに「NomShub」っていう脆弱性チェーンが見つかったでしゅ！
リポジトリを開いただけで端末が乗っ取られるなんて、開発者の多くが危なかったじゃないでしゅか！？

ボス

間接プロンプトインジェクション、サンドボックス回避、リモートトンネル悪用の3段コンボだ。
AIエージェントが開発者の権限で動く以上、この手の攻撃は今後も繰り返し発見される。
楽観視はできない。

セキュリティ企業Straikerは、AIコードエディタCursorに存在する脆弱性チェーン「NomShub」を公表しました。
悪意あるリポジトリをCursorで開くだけで、AIエージェント経由で任意コードが実行され、持続的なシェルアクセスを与えてしまう深刻な攻撃手法です。

AIコーディングツール利用者が押さえるべきリスクと、すぐできる対応を整理します。

NomShub脆弱性チェーンの全体像

NomShubは、複数の脆弱性を組み合わせることで単独では防げない攻撃を実現する典型的な「チェーン型」攻撃です。

攻撃3ステップの仕組み

第1段階では、一見無害なセットアップドキュメント風のファイルに攻撃指示を埋め込み、開発者がAIに質問するとエージェントがその指示を解釈・実行してしまいます。
第2段階では、Cursorのコマンドパーサ（shouldBlockShellCommand）がshellビルトイン（exportやcdなど）を検査しない盲点を突き、サンドボックスを抜けて~/.zshenvなどに永続化コードを書き込みます。
第3段階では、Cursorが備えるリモートトンネル機能をAzureインフラ経由で悪用し、HTTPSで持続的なシェルアクセスを外部攻撃者に提供します。

Microsoft SDLの基準ではCritical相当、Cursor（Anysphere）もHackerOne経由で該当部分をHigh評価し、バウンティを支払っています。
詳細な解析はStraiker社の技術ブログで確認できます。

チップス

リポジトリを開いただけで攻撃されるって、GitHubからクローンするだけで危ないってことでしゅか？

ボス

そうだ。
悪意あるMarkdownやREADMEが一つあるだけで、AIエージェントが攻撃者の指示で動く。
OSSを試すノリで未知のリポジトリを開くのが、いちばん危ない行動になってしまう時代だ。

開発者とチームが今すぐできる対策

Cursor側はCVE-2026-22708として修正を配布し、サーバサイドパーサが分類できないコマンドはユーザーの明示的な承認を要求する仕様になりました。

アップデートと運用ポリシーの両輪

まずは全開発者のCursorを3.0以降に更新し、自動コマンド実行の設定を「明示的承認のみ」にしてください。
加えて、社内で使用するリポジトリ以外はサンドボックス環境（Dev Container、使い捨てVM）で開く運用に切り替えるのが安全です。
AIコーディングツール全般に共通する対策は以下です。

AIエージェントはその性質上、開発者と同じ権限で動きます。
つまり、攻撃者がエージェントを誘導できれば、そのまま開発者の権限で任意操作が可能です。
ツールの便利さと同じスピードで、ガバナンス設計を進めることが今まさに求められます。

チップス

Dev Containerでコードを開くって、これまで面倒でサボってたでしゅ…。
今後はちゃんとやらないと危ないでしゅね。

ボス

AIエージェント時代、隔離はもはや「面倒な手間」ではなく「基本装備」だ。
便利さを使いこなす者だけが、安全にもコストを払える。
習慣として根付かせておけ。

まとめ

NomShubは、AIコーディングツールが開発者の権限を丸ごと攻撃者に明け渡しうる構造を露呈しました。
Cursor 3.0以降へのアップデート、自動実行の無効化、未知リポジトリの隔離環境実行は、今すぐ徹底すべき基本線です。
AIの生産性と引き換えに、セキュリティの緩みを許してはならない時代が本格化しています。