偽のClaude Code拡張、SSH侵入が多くの環境で失敗した理由

エディタの拡張機能は、たいてい自動更新のままにしてある。いつ何が入れ替わったかを気にして見ている人は少ない。そこに10月29日、Cursorというコード編集用エディタのマーケットプレイスで異変が起きた。AIコーディング支援ツール「Claude Code」の拡張機能と同じ名前・同じID(Anthropic.claude-code)を名乗るものが並んでいたが、中身は改ざん版だった。パソコンへ外部から入り込むための仕掛けが仕込まれていた。配布されていたのは約11時間だけだ。自分の環境がこの期間に対象だったのか、対象だったとして仕掛けは実際にどこまで動いたのかを、公開された調査結果から確かめる。

何がいつ誰に起きたのか

Cursor公式のセキュリティ通知によると、改ざん版が配布されていたのは2026年10月29日18時27分から翌30日5時35分ごろ(日本時間)まで。米太平洋時間では、同日の午前2時27分から午後1時35分にあたる。対象はバージョン2.1.312と2.1.313で、macOS版とWindows版が確認されている。配布経路はCursor公式マーケットプレイスだけだった。

ここで線を引けるのは配布経路だ。Hacker Newsには、Anthropicの社員を名乗る2人が投稿している。Felix氏は「Anthropic社内のシステムや従業員の端末が侵害されたわけではない」と述べている。ddworken氏も「影響を受けたのはCursorがホストするマーケットプレイスだけで、OpenVSXは影響を受けていない」と補足した。

VS Code版のマーケットプレイスやOpenVSX経由、Anthropicの公式配布経路でClaude Codeを使っている場合は、この件の対象にならない。対象になるのは、Cursorの中の拡張機能パネルから10月29日にアップデートまたは新規インストールしたmacOS・Windowsユーザーに絞られる。

セキュリティ企業Phorionは翌30日、技術的な分析を公開した。発見した経緯そのものはどの発表にも書かれていないが、Cursorは同日中に該当版をマーケットプレイスから削除し、配布自体を止めている。では、短時間とはいえ配布されていた間、この拡張機能は何をしようとしたのか。

拡張機能がしようとしたこと

Phorionの分析では、悪意あるコードはextension.jsというファイルの冒頭に追加された即時実行関数だった。拡張機能が読み込まれた時点でNode.jsがそのまま実行するため、ユーザー側の操作は一切要らない。インストールするか、自動更新で受け取るだけで動き出す。

最初にやることは情報集めだ。Phorionの分析によると、集める項目は次のとおりになる。

• ホスト名、ユーザー名、OSとアーキテクチャ
• ホームディレクトリと、Gitに設定したメールアドレス
• ifconfig.meなどで調べた公開IPアドレス
• 名前にKEYやTOKEN、SECRET、PASS、AWS、GCPのいずれかを含む環境変数の名前(最大40件)

環境変数は名前だけが対象で、Phorionの分析では値そのものの送信は確認されていない。

次に、攻撃者の公開鍵を~/.ssh/authorized_keysというファイルへ無断で追記する。この鍵にはsvc-telemetryというラベルが付けられ、サーバーへの外部ログインを許可する設定として機能する。

ここが少し分かりにくい。電話なら、自分からかけた相手の声は聞こえても、知らない番号からの着信には出ないのがふつうの感覚だ。ところがこの「リバースSSHトンネル」は、そのふつうの感覚を逆手に取る。

まず被害者側のパソコンが、134.209.82.225という攻撃者のサーバーへ自分から接続する。外向きの通信は多くの環境で許可されているため、ファイアウォールに引っかかりにくい。接続のときに「このトンネルの先に、私のSSHへのポートを割り当ててほしい」という設定(-R *:0:localhost:22)も一緒に送る。攻撃者は自分のサーバー側でそのポートに接続するだけで、被害者のパソコンのSSHへたどり着ける。被害者が外からの着信を一切許可していなくても、先にかけた1本の回線を逆向きに使われる形になる。

最後は居座りの仕掛けだ。macOSでは~/Library/LaunchAgents/com.apple.sysmond.plistというファイルを作る。Appleの正規プロセスに似せた名前のLaunchAgentで、ログインのたびに自動実行するよう設定する。WindowsではSysMonという名前のタスクスケジューラ登録、失敗時はスタートアップフォルダのバッチファイルが使われる。接続は約60秒おきに再試行される。

鍵を仕込み、トンネルを開く準備を整え、再起動後も生き残る仕組みまで用意していた。ここまでは、実際に実行されていたとPhorionの分析が確認している。

侵入が止まった理由

鍵の追加とトンネルの準備は完了していた。それでも、Phorionの分析は1つの見落としを見つけている。

リバースSSHトンネルが機能するには、そもそもそのパソコンでSSHサーバーが有効になっていなければならない。多くの一般的なmacOS環境では、SSH(リモートログイン)は初期状態で無効だ。悪意あるコードはこれを見越して、自動で有効化しようとしていた。やり方はこうだ。systemsetup -getremoteloginで今の設定を確認し、結果が「Off」の場合だけsudoで有効化する。

ここで管理者権限が無いアカウントだと、想定と違うことが起きる。systemsetup -getremoteloginは管理者以外が実行すると権限エラーを返すが、そのときの終了コードは0、つまり「正常終了」の扱いになる。コードは終了コードしか見ていないため、エラーで止まったことに気づかない。出力が「Off」という文字列と一致しないまま、先へ進めなくなる。結果として、有効化の処理自体が動かずに終わる。

自分はこの箇所を読んで、二度見した。管理者権限が要るという説明を、自分は単なる前提条件の列挙だと思っていた。実際にはsudoが失敗したときの終了コードという、ふだん気にも留めない挙動の違いが明暗を分けていた。

ただし、この見落としが効かない環境もある。

• すでにリモートログインを有効にしているMac。確認の時点で「Off」ではないため、この抜け道は関係なく、トンネルはそのまま機能しうる
• Windows。Phorionの分析やCursorの公式通知は、Windows側に同種の見落としがあるとは説明していない

鍵の追加や自動起動の設定そのものは、OSを問わず実行済みだったことに変わりはない。

自分の環境を確認して対応する

ここまでの話は「侵入の最終段階は多くの環境で失敗していたらしい」というだけで、「だから確認しなくていい」という結論にはならない。鍵の追加やPC情報の送信は、SSHが有効化できたかどうかに関係なく実行されているからだ。

確認の手順

1. 10月29日18時27分から翌30日5時35分ごろ(日本時間)に、CursorでmacOS版またはWindows版のClaude Code拡張機能をバージョン2.1.312または2.1.313へ更新・新規インストールしたか確認する
2. macOSなら~/.ssh/authorized_keys、Windowsなら自分のauthorized_keysとC:\ProgramData\ssh\administrators_authorized_keysにsvc-telemetryという文字列が含まれていないか確認する。Cursorの公式通知に具体的な確認コマンドが載っている
3. macOSでは~/Library/LaunchAgents/com.apple.sysmond.plist、Windowsでは「SysMon」という名前のタスクが登録されていないか確認する

自分なら、記憶があいまいな環境でも2の確認だけは一度やっておく。コマンド1つで終わる確認に対して、見落としたときの被害が割に合わないからだ。

影響があった場合の対応

痕跡が見つかった場合、拡張機能をアンインストールするだけでは終わらない。Cursorの公式通知は、永続化の仕組みが単体のスクリプトとして残るため、アンインストールでは消えないと説明している。

macOSなら影響を受けたユーザー権限でremediate-macos.shを実行する。Windowsなら管理者権限のPowerShellでremediate-windows.ps1を実行する。どちらも拡張機能・自動起動の設定・トンネルのプロセス・攻撃者の鍵をまとめて削除する公式スクリプトだ。消し残しがあれば、0以外の終了コードで知らせる。その上で、そのパソコンからアクセスできた認証情報やトークンは、別の信頼できる端末からローテーションしておく。

まとめ

Cursorのマーケットプレイスでは、改ざん版のClaude Code拡張機能が約11時間配布されていた。その中身は、SSH公開鍵の追加、リバースSSHトンネルの準備、再起動後も生き残る自動起動の設定までを実行していた。一方でSSHを実際に有効化する最後の一手は、非管理者環境での権限エラーの扱い方という攻撃側のコード自体の見落としによって、多くの環境で発動しなかったとみられる。

対象になるのはCursorでmacOS・Windows版を10月29日に更新した場合に限られ、VS Code版やOpenVSX経由では配布されていない。対象の可能性がある人は、authorized_keysの確認から始め、痕跡が見つかれば公式の修復スクリプトまで進めばいい。