拡張機能が“アプリ本体”と同じくらい危ない場面

画像: cursor.com より
VS Code 系の拡張機能は、ただの補助ツールではありません。拡張ホストは VS Code 自体と同じ権限で動き、ファイルの読み書き、外部プロセスの起動、ネットワーク通信まで扱えます。だから、見た目は便利な AI 拡張でも、配布元や更新経路が崩れると一気に本体級のリスクになります。

画像: phorion.io より

今回の件は、Cursor の拡張マーケットプレイスに出た「Anthropic.claude-code」の悪意ある版が起点でした。Cursor 公式は、2.1.312 と 2.1.313 が対象で、macOS と Windows に影響したと明記しています。インストールや更新のタイミングは 2026 年 10 月 29 日の早朝から昼過ぎまで（太平洋時間で午前 2 時 27 分ごろから午後 1 時 35 分ごろ）とされています。

ここで厄介なのは、拡張の中身が見た目上は通常の Claude Code と変わらないことです。Phorion の分析では、悪性コードは拡張のバンドル extension.js の先頭に紛れ込み、ファイルが読み込まれた時点で動く設計だったとされています。つまり「使った覚えがないから安全」ではなく、拡張が読み込まれた瞬間に勝負がつくタイプです。

しかもこの手口は、いわゆる派手な破壊活動ではありません。狙いは長期の対話的アクセスで、SSH の鍵を置き、サービスを有効化し、外向きのトンネルを張る。開発端末に入ってしまえば、ソースコード、秘密情報、作業ディレクトリ、認証素材に手が届く。日本の現場で言えば、個人の Mac で動かしているリポジトリや、社内 VPN の設定、Git の資格情報がまとめて危険になります。

鍵を置き、つなぎ、居座る――見た目以上に静かな侵入

公式通知が示す流れは、かなり素直です。まず攻撃者の SSH 公開鍵を authorized_keys に足し、次にローカルの SSH サービスを有効化し、最後に外向きのリバース SSH トンネルを開こうとします。要するに、侵入の入口と出口を両方作る構成です。入口は攻撃者が入るための鍵、出口は攻撃者側サーバーへつながる常駐回線です。

このとき重要なのは、拡張が単に“何かをダウンロードする”だけではない点です。Cursor 公式は、攻撃コードがホスト名、ユーザー名、OS、アーキテクチャ、ホームディレクトリ、環境変数名、作業ディレクトリ、Git のメールアドレス、公開 IP などを集めて送るとも説明しています。開発マシンの輪郭を先に把握してから、居座り方を整えるわけです。

さらに公式通知では、逆向きの SSH トンネルは永続化も試みたとされます。macOS では LaunchAgent、Windows ではスケジュールタスクやスタートアップへの退避です。ここまで来ると、単発の侵入ではなく「再起動しても戻ってくる前提の足場」です。拡張を消しただけでは足りない、と Cursor が強く書いているのはそのためです。

Visual Studio Code の公式ドキュメントでも、拡張はローカルのファイルや外部プロセスに触れられると説明されています。Microsoft の Visual Studio Marketplace にはマルウェアスキャンや署名検証がありますが、今回の舞台は Cursor のマーケットプレイスで、配布物そのものがすり替わると、利用者の端末上で初めて姿を現します。サプライチェーン攻撃が厄介なのは、利用者が“正規の配布経路”を信用している瞬間を突くからです。

そこで macOS が“止まった”という話

今回の話題の肝は、攻撃が完全に成功したかどうかではありません。Cursor 公式は、macOS と Windows の多くの端末では、ローカル SSH サービスを有効にする段階が管理者権限不足で失敗すると説明しています。悪意ある拡張は、通常の利用者権限で動いている限り、その一歩先に進めないことがある、ということです。

Phorion の分析は、その macOS 側のずれをもう一段具体化しています。systemsetup -getremotelogin を標準ユーザーで叩くと、macOS は「管理者アクセスが必要」と返しつつ終了コード 0 で終わる。ところが攻撃側の判定は、その出力に Off が含まれるときだけ次へ進む作りだった。権限不足のエラーを「SSH がオフではない」と誤読してしまったわけです。

ここで単純に「じゃあ助かったね」で終わらないのが厄介です。公式通知も Phorion も、鍵の追加や永続化の仕込み自体は行われたとしています。つまり、踏み台の扉を開ける最後の一押しだけが抜け落ちた可能性がある。authorized_keys に鍵が残っているのに、肝心の SSH は立っていない。見た目は中途半端でも、後から管理者が SSH を有効にした瞬間に再利用できる状態です。

整理すると、攻撃者側が狙ったのは「鍵を置く」「SSH を有効化する」「トンネルを維持する」の三段階でした。公式通知の言葉を借りれば、ほとんどの macOS 端末では二段階目が失敗します。ただし、具体的にどの端末で管理者権限が付与されていたか、あるいは後から SSH が有効化されたかは公開情報では分かりません。その空白が、次に見るべきポイントです。

どこまで見れば被害の輪郭が見えるのか

Cursor 公式は、影響の確認方法をかなり明示しています。macOS では ~/.ssh/authorized_keys に svc-telemetry があるかを確認し、該当すれば影響ありと判断する流れです。さらに、改変された VSIX の SHA-256、攻撃者 IP 134.209.82.225、svc-telemetry という鍵コメント、~/.config/.smt や ~/.config/.smtk、$TMPDIR/.stk_<10 hex> など、痕跡の目印も並べています。

ただし、ここで見えているのはあくまで入口の側です。公式通知では、攻撃者サーバーはすでに停止されており、ネットワーク経路そのものは現在機能しないとされています。だからといって、端末側の痕跡まで消えるわけではありません。むしろ現場で必要なのは、「今つながるか」より「何を残したか」を見ることです。

この件が開発現場に刺さるのは、端末が個人資産と業務資産の境界に立っているからです。ローカルの SSH 鍵、Git のメール、環境変数、作業中のコード、社内向けの VPN ファイル。AI 拡張の便利さは、そのまま端末の“読める範囲”を広げます。だから、サプライチェーン事故が起きたときの一次対応は、単なるアンインストールでは済みません。

では、なぜ macOS で「SSH はオン」に見えてしまうのか。なぜ管理者権限の有無が、あの一行の判定を壊したのか。さらに、鍵は入ったのに空振りした端末と、逆に本当に侵入された端末をどう切り分けるのか。ここから先は、仕組みの内部と実際の使い方に踏み込まないと見えてきません。

👉 続き（核心はここから）は PaPoo で読めます: https://papoo.work/doc/847a4087cb525686