2026年10月29日、北京時間17:27から翌04:35までの約11時間、Cursor拡張機能マーケットプレイスにある公式Claude Code拡張機能が、SSHバックドアを仕込んだ悪意あるビルドに置き換えられました。影響を受けたバージョンは2.1.312と2.1.313で、対象プラットフォームはmacOS arm64とWindows x64です。Cursorによると、最大約5,000人のユーザーがこのビルドをダウンロード、または自動更新した可能性があります。
偽の拡張機能がマーケットプレイスに紛れ込んだわけではありません。 ユーザーがインストールしたパッケージ名は公式の Anthropic.claude-code で、画面も機能も普段と変わらなかったため、インストールしたことに気づいていない人も多くいます。そのため、拡張機能のアンインストールやバージョンアップだけでは不十分です。悪意あるコードはSSH公開鍵を書き込み、起動時に自動実行される永続化スクリプトを設定し、ホスト情報を攻撃者に送信していました。対応すべきことは、鍵の削除、永続化の解除、認証情報のローテーションの3つです。
この記事でわかること：「何が表示されるか → 何をするか → 成功したかどうかの判断方法」の順に、5つのステップで解説します。セキュリティの専門家でない開発者でも、手順に沿って進めれば、APIYIのAPIキーのローテーションを含む確認とクリーンアップを約30分で完了できます。
図注：悪意あるビルドの配布期間は約11時間。2.1.314はインシデント後にリリースされた最初のクリーン版です。
まずは落ち着いて：Claude Code 拡張機能への不正コード混入で何が起きたのか
まずは事実を整理しましょう。以下の情報はすべて、Cursor のセキュリティ公告と Anthropic 社員の公式な発言に基づいています。
| 項目 | 事実 |
|---|---|
| 事件 | Cursor 拡張機能マーケットプレイスの Anthropic.claude-code が改ざんされ、永続化する SSH バックドアが仕込まれた |
| 影響を受けるバージョン | 2.1.312 と 2.1.313（Cursor は 10 月 30 日の公告更新時に 2.1.312 を追加） |
| プラットフォーム | macOS（darwin-arm64）、Windows（win32-x64）。コードには Linux 向けの分岐もある |
| 曝露期間 | 太平洋時間 10/29 02:27〜13:35、北京時間では 10/29 17:27〜10/30 04:35 |
| 影響範囲 | Cursor によると最大 5,000 ユーザー。これは曝露の推定数であり、感染が確認された人数ではない |
| 現在の状況 | 悪意のあるバージョンは公開停止済み。マーケットプレイスは閉鎖、再構築、監査を経て復旧済み。Cursor によると、攻撃者のサーバーはホスティング事業者によって停止された |
| 安全なバージョン | 2.1.314 が最初の安全なバージョン。10 月 31 日時点の最新版は 2.1.316 |
キャプション：Cursor セキュリティ公告ページのスクリーンショット（編集段階で追加）。
事件発覚当初に広まった情報には、いくつか誤りがありました。次の 3 点を訂正しておきます。
- 2.1.312 も影響を受けるバージョンに含まれます。 Cursor は当初 2.1.313 のみを公表していましたが、その後 2.1.312 を追加しました。曝露期間中に Cursor マーケットプレイスから 2.1.312 をインストールした場合も、確認が必要です。
- 不正コードが混入したのは Cursor Marketplace のみです。 当初、Open VSX、Microsoft のマーケットプレイス、npm にも影響があったとの報道がありましたが、これらは訂正されています。Socket がレジストリの変更履歴を監査したところ、2.1.313 が公開または削除された記録は見つかりませんでした。
- 2.1.313 は Anthropic の公式チャネルでは一度も公開されていません。 Anthropic のセキュリティエンジニア David Dworken 氏によると、このバージョンは Open VSX、VS Code 公式マーケットプレイス、Anthropic の公式ホストのいずれにも存在していません。バージョン番号の混乱を避けるため、次の公式バージョンは 2.1.314 に飛ばされました。
誰が実行したのか、どうやって公開権限を得たのかについては、現時点で答えが出ていません。Anthropic の Felix Rieseberg 氏は、Anthropic のシステムや社員のパソコンが侵害されたのではなく、何者かが Cursor マーケットプレイスへのアクセス権を利用して改ざん版を公開したと述べています。一方、Cursor の公告では、攻撃者が公開権限をどう取得したかは説明されていません。Cursor はこれに先立つ 10 月に Marketplace への一般からの投稿を受け付け始めていますが、今回の不正コード混入との関連について公式な説明はなく、この記事でも推測はしません。開発者にとっては、根本原因を推測するよりも、まず自分のマシンを確認することが大切です。
なぜ公式 Claude Code 拡張機能にも悪意あるコードが仕込まれたのか
「公式のパッケージ名なのに、なぜ悪意あるコードが入っているの？」と思うかもしれません。これを理解するには、まず IDE 拡張機能の動作を知る必要があります。拡張機能は IDE と同じ権限で動作し、コードや環境変数、ユーザーディレクトリ内のファイルを読み書きできます。しかも、読み込まれた時点でコードが実行されるため、ダイアログを開いたり、拡張機能を実際に使ったりする必要はありません。
Phorion の分析によると、悪意あるコードは 66 行の即時実行関数（IIFE）で、extension.js ファイルの先頭に挿入されていました。その後ろには、通常の拡張機能のコードが続いています。拡張機能のモジュールが Node に読み込まれると、このコードは通常の activate コールバックより先に実行されます。改ざんされた extension.js のサイズは 3,692,922 バイトで、直前のクリーンなバージョンより約 7 KB 大きくなっていました。npm の postinstall フックには依存していないため、これは npm パッケージへの攻撃ではなく、VSIX インストールパッケージ内のコードが直接改ざんされたケースです。
たとえるなら、偽薬が薬局に紛れ込んだのではなく、公式の棚にある正規ブランドの薬が、別の薬を混ぜたものにすり替えられたようなものです。名前も包装もバーコードも本物ですが、中身だけが違います。そのため、今回の事件では「公式の発行元を確認すれば安心」という従来の対策は通用しませんでした。
図注：バックドアの連鎖は全部で6段階。拡張機能のアンインストールで止められるのは最初の段階だけです。
この事件について、よくある誤解が3つあります。
- 「公式のパッケージ名なら公式ビルドだ」：今回のパッケージ名と発行者の身元は公式のものでしたが、ビルドは Anthropic が行ったものではありません。Open VSX にも同じ 2.1.312 が存在しますが、こちらは 10 月 27 日に公開されたクリーンなバージョンです。同じバージョン番号でも、入手元が違えば安全性も異なります。
- 「問題があるのは 2.1.313 だけだ」：Cursor のマーケットプレイスにあった 2.1.312 にも悪意あるコードが含まれていました。
- 「アンインストールやアップグレードをすれば大丈夫だ」：Cursor の告知によると、拡張機能をアンインストールするだけでは不十分な可能性があります。ペイロードが、独立して動作する永続化スクリプトを残すためです。
Claude Code 拡張機能のバックドアを5ステップで確認・削除
以下の5ステップを順番に進めてください。最初の3ステップで確認し、4ステップ目で削除、5ステップ目で仕上げを行います。各ステップには、作業内容と完了の判断基準を記載しています。
図：5ステップの流れ。5ステップ目の認証情報のローテーションも必ず行ってください。
① 拡張機能のバージョンと入手元を確認。 Cursorの拡張機能パネルを開き、Claude Codeを検索して、バージョン番号と発行元を確認します。次に、ターミナルで ~/.cursor/extensions/ ディレクトリ（Windowsでは %USERPROFILE%\.cursor\extensions\）を確認し、名前に anthropic.claude-code-2.1.312 または 2.1.313 を含むフォルダがないか調べます。現在は新しいバージョンを使っていても、旧バージョンのディレクトリが残っていれば、問題が発生していた期間中にインストールした可能性があります。
② svc-telemetry 公開鍵を確認。 macOSとLinuxでは grep -n svc-telemetry ~/.ssh/authorized_keys を実行します。Windowsでは %USERPROFILE%\.ssh\authorized_keys と C:\ProgramData\ssh\administrators_authorized_keys の両方を確認してください。悪意のあるコードは、ファイル内に svc-telemetry という文字列があるかどうかで判断するため、コメントだけを見るのでは不十分です。さらに ssh-keygen -lf ~/.ssh/authorized_keys を実行してすべての公開鍵のフィンガープリントを一覧表示し、攻撃者のフィンガープリント SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk と一つずつ照合することをおすすめします。
③ 永続化とトンネルプロセスを確認。 確認する場所はOSによって異なります。
- macOS：
~/Library/LaunchAgents/com.apple.sysmond.plist、~/.config/.smt、~/.config/.smtk、および一時ディレクトリ内の.stk_*ファイルを確認します。このLaunchAgentの名前はAppleのシステムコンポーネントを装っていますが、実際にはユーザーレベルの起動項目です。 - Windows：
schtasks /query /tn SysMonを実行してタスクスケジューラのタスクを確認します。スタートアップフォルダ内のsysmon.cmd、および%USERPROFILE%\.config\smt.cmd、%TEMP%\.stk_*も確認します。 - Linux：
crontab -lを実行し、@rebootを含み、~/.config/.smtを指すエントリを探します。 - すべてのプラットフォーム：
sshまたはautosshプロセスの引数に-R '*:0:localhost:22'が含まれていないか確認します。
| ステップ | 作業内容 | 完了の判断基準 |
|---|---|---|
| ① 拡張機能の入手元 | 拡張機能パネルと ~/.cursor/extensions/ を確認 |
2.1.312 / 2.1.313 のディレクトリがなく、現在のバージョンが2.1.314以上 |
| ② 公開鍵 | svc-telemetry を検索し、フィンガープリントを照合 |
2種類の authorized_keys のどちらにも一致する項目がない |
| ③ 永続化 | plist / SysMon / cron / トンネルプロセスを確認 | ファイルが存在せず、-R 引数を持つsshプロセスがない |
| ④ 削除 | Cursor公式スクリプトを実行してアップグレード | スクリプトが終了ステータス0で終了し、①②③を再確認しても該当項目がない |
| ⑤ 認証情報 | Git、CI、クラウド、SSH、APIキーをローテーション | 古い認証情報が無効化され、呼び出しログに異常がない |
④ 感染が確認されたら、公式スクリプトで駆除する。 ②または③のいずれかに該当する場合は、Cursorの公告に従って対応してください。macOSユーザーは cursor.com/static/security/claude-code-extension/remediate-macos.sh をダウンロードし、影響を受けたユーザーの権限で（rootは使わずに）bash remediate-macos.sh を実行します。Windowsユーザーは remediate-windows.ps1 をダウンロードし、PowerShellを「管理者として実行」で開いて、powershell -ExecutionPolicy Bypass -File .\remediate-windows.ps1 を実行します。スクリプトは必ずCursorの公式サイトから入手し、出所不明の「ワンクリック駆除」ツールは使わないでください。スクリプトは悪意ある拡張機能、永続化の仕組み、トンネルプロセス、攻撃者の公開鍵を削除します。残存物がある場合は、終了ステータスが非0になります。駆除後は拡張機能を2.1.314以上にアップグレードしてください。10月31日時点では、2.1.316を直接インストールできます。
⑤ 認証情報をローテーションする。 対象には、GitHub / GitLabトークン、CI/CDトークン、クラウド事業者のアクセスキー、SSH秘密鍵、npm / PyPIトークン、そしてこのマシンに設定したAPIYI（apiyi.com）のAPIキーが含まれます。ローテーションは信頼できる別のマシンで行ってください。SSHログからトンネルが実際に使用されたことが確認された場合、Phorionはホストの再構築を推奨しています。一つずつ駆除するよりも安全な方法です。
多くの環境でログインされなかった理由と、Claude Codeのバックドアを確認すべき理由
まずは、少し安心できる話から。Phorionの分析によると、悪意あるコード自体にバグがあり、大多数のホストではSSHサービスの起動に失敗していました。
macOSでは、スクリプトが一般ユーザーの権限で systemsetup -getremotelogin を実行すると、「管理者権限が必要」というメッセージが返されますが、終了コードは0のままです。スクリプトは出力に Off が含まれているかどうかしか確認していません。このメッセージには Off がないため、リモートログインがすでに有効だと誤認し、SSHを有効にする手順をスキップしていました。
Windowsでは、OpenSSH ServerをインストールするPowerShellコマンドが、/bin/sh を固定指定した補助関数に渡されていました。標準的なWindowsには /bin/sh がないため、この手順は失敗した可能性が高いと考えられます。Cursorも、Cursorを管理者権限で起動していない限り、SSHサービスの有効化とトンネルの構築は失敗するとしています。管理者権限で起動するケースはまれです。
しかし、だからといって安心はできません。公開鍵、永続化スクリプト、偵察用ビーコンはすでに配置されています。たとえるなら、犯人の解錠ツールが壊れていたため、多くのドアは開かなかったものの、鍵はすでに鍵穴に挿されており、60秒ごとに再び開けようとしている状態です。
| カテゴリ | 指標（IOC、無害化処理済み） | 説明 |
|---|---|---|
| ネットワーク | 134[.]209[.]82[.]225:22、ユーザー名 tunnel |
リバースSSHトンネルの接続先 |
| ネットワーク | 134[.]209[.]82[.]225:8099/beacon |
平文HTTPビーコン。ホスト情報を送信 |
| 公開鍵 | コメント svc-telemetry |
authorized_keys に書き込まれる |
| フィンガープリント | SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk |
攻撃者の公開鍵のフィンガープリント |
| トンネル用秘密鍵 | SHA256:KOAU57+ZG6u3MG4WwzPzPX2O5YEe9qdOC1Bl+6MVyDQ |
一時ディレクトリの .stk_* ファイルに書き込まれる |
| ファイル | extension.js のSHA-256は ecb58cb2 で始まる |
悪意ある拡張機能のメインファイル。完全な値はCursorの告知を参照 |
図：悪意あるVSIXのハッシュ表のスクリーンショット（編集段階で追加）。
次のようなケースには特に注意が必要です。
- リモートログインがもともと有効だった。 Macの「システム設定 → 一般 → 共有」でリモートログインを有効にしていた場合や、Windowsで
Get-Service sshdを実行してサービスが稼働中と表示される場合、バックドアが利用可能な条件を満たしています。 - サーバーが停止しても、マシンが安全になったとは限らない。 攻撃者のサーバーは現在停止していますが、永続化スクリプトは接続を繰り返し試みます。削除しなければ、そのマシンは危険な状態のままです。
- SSHのログインログを確認する。 macOSでは
log show --predicate 'process == "sshd"' --last 7dを実行し、Linuxでは/var/log/auth.log、WindowsではイベントビューアーのOpenSSH/Operationalログを確認します。特に、127.0.0.1または::1からの接続で、svc-telemetry公開鍵による認証に成功した記録を探してください。1件でも見つかった場合は「ログインされた」と判断し、ホストの再構築を検討します。
悪意あるコードは、ホスト名、ユーザー名、システム情報、作業ディレクトリ、Gitのグローバル設定に登録されたメールアドレス、パブリックIPアドレス、最大40個の環境変数名も収集していました。Phorionの結論は明快です。バグによってログインされる可能性は下がりましたが、それを防御策と考えることはできません。
Claude Code拡張機能が改ざんされたら、APIYIのAPIキーは交換すべき？
交換してください。 悪意のあるコードが収集したのは、名前にKEY、TOKEN、SECRET、PASS、AWS、GCPを含む環境変数の名前です。変数の値は直接読み取られていませんが、攻撃者はあなたのマシンにどのような認証情報があるかを把握しています。トンネルが利用可能になると、攻撃者は環境変数の値や設定ファイル、シェル履歴を対話的に読み取れるようになります。そのため、対象期間中にこのマシンに2.1.312または2.1.313をインストールしていた場合、設定されているAPIYI apiyi.comのAPIキーは「漏えいした可能性がある」ものとして扱うべきです。
まず明確にしておきたいのは、APIYIが侵害されたわけではないという点です。リスクがあるのは、ローカルマシン上のAPIキーが間接的に読み取られる可能性です。慌てずにAPIキーをローテーションしましょう。具体的な手順は次のとおりです。
| 手順 | 操作 | 確認事項 |
|---|---|---|
| 1 | コンソールのトークンページ api.apiyi.com/token を開く |
既存のAPIキーの一覧が表示される |
| 2 | 右上の「新增」をクリックし、Claude Code用のAPIキーのグループに ClaudeCode を選ぶ |
sk- で始まる新しいAPIキーが生成される |
| 3 | ANTHROPIC_AUTH_TOKEN を新しいAPIキーに変更し、ANTHROPIC_BASE_URL は https://api.apiyi.com のままにする |
~/.claude/settings.json 内のenvも同様に変更する |
| 4 | ターミナルを開き直し、Claude Codeを再起動する | 正常に対話や呼び出しができる |
| 5 | トークンページに戻り、古いAPIキーを無効化または削除する | 古いAPIキーのステータスが無効になる |
| 6 | 呼び出しログを確認する | 見覚えのないモデルや時間帯の消費がない |
スクリプトでOpenAI互換インターフェースを使用している場合は、コード内の base_url="https://api.apiyi.com/v1" に対応するAPIキーも忘れずに交換してください。交換後は新しいAPIキーでテストリクエストを送り、利用できることを確認しましょう。古いAPIキーをほかのマシンやプロジェクトでも使用している場合は、1台だけでなく、それぞれで交換してください。
🎯 ベストプラクティス：APIYI apiyi.comのトークンページでは、APIキーごとに残高の上限と有効期限を設定できます。「1台のマシンに1つのAPIキー」「開発用と本番用を分ける」という方法で管理しておくと、次に同様の問題が起きた際、該当するAPIキーだけを無効化できます。
また、改めて強調しておくと、ローテーションが必要なのはAPIYIのAPIキーだけではありません。GitHub / GitLabのトークン、CIの認証情報、クラウド事業者のアクセスキー、SSH秘密鍵、npm / PyPIのトークンもすべてローテーションし、作業は信頼できるマシンで行ってください。
Claude Code拡張機能の汚染に関するよくある質問（FAQ）
Q1：VS Codeの公式マーケットプレイスだけを使っています。影響はありますか？
現時点では、影響を受けるという証拠はありません。確認されている配布元はCursor Marketplaceのみで、Microsoft MarketplaceとOpen VSXには悪意のある2.1.313は存在しません。
Q2：Claude Code CLIだけを使っていて、IDE拡張機能は使っていません。影響はありますか？
今回の事件による影響はありません。npm上のCLIパッケージは汚染されておらず、影響を受けたのはCursor Marketplace内の拡張機能のVSIXだけです。
Q3：Cursorを使っていますが、Claude Code拡張機能はインストールしていません。影響はありますか？
ありません。悪意のあるコードは、この拡張機能が読み込まれたときにのみ実行されます。心配な場合は、手順②に従って `svc-telemetry` を検索すれば、数秒で確認できます。
Q4：2.1.314にアップグレードすれば安全ですか？
アップグレードによって防げるのは、今後の被害だけです。すでに書き込まれた公開鍵や永続化スクリプト、流出した情報はアップグレードしても消えないため、引き続き手順②③④⑤に従って対処する必要があります。
Q5：今は2.1.316をインストールすべきですか？
インストールして問題ありません。10月31日時点で、2.1.316はGitHub Releases上の最新版です。2.1.314と2.1.316はいずれも問題のないバージョンです。その間に2.1.315が存在しないのは正常です。
Q6：OSを再インストールする必要はありますか？
公開鍵や永続化の痕跡だけが見つかった場合は、公式スクリプトを実行して再確認すれば、通常は十分です。SSHログにトンネルが実際に使われた形跡がある場合は、Phorionはホストの再構築を推奨しています。攻撃者がログイン後に何をしたかは、サンプルから推測できないためです。
Q7：5,000人は感染が確認された人数ですか？
いいえ。Cursorが発表した「最大5,000人のユーザー」は、ダウンロードと自動更新によって影響を受けた可能性のある人数の推定値であり、感染が確認された人数ではありません。Cursorは、影響を受けたユーザーに直接連絡するとしています。
Q8：自分のパソコンが遠隔操作される可能性はありますか？
前述のバグにより、ほとんどのmacOSおよびWindowsホストではSSHサービスが有効にならず、攻撃者のサーバーも現在は停止しています。ただし、リモートログイン機能をもともと有効にしていた場合は、実際にリスクがあります。ログインされた形跡があるかどうかは、SSHログで確認してください。
Q9：APIYIのAPIキーが流出する可能性はありますか？
APIYIのプラットフォーム自体は侵入されていません。リスクは、お使いの端末の環境変数が読み取られた可能性があることです。そのため、api.apiyi.com/token で新しいAPIキーを作成し、設定を変更したうえで、古いAPIキーを無効化することをおすすめします。
Claude Code拡張機能へのマルウェア混入：重要ポイント Key Takeaways
- 影響を受けるバージョン：Cursorマーケットプレイスの2.1.312と2.1.313。公式の他の配布経路は影響を受けていません。
- 読み込み時に実行：拡張機能を使用する必要はなく、読み込まれるだけでバックドアが仕込まれます。
- 残留する3つの痕跡：authorized_keys内の公開鍵、永続化スクリプト、ビーコンによって外部に送信された情報。
- 大多数は不正ログインを受けていない：悪意あるコードにバグがあったためですが、調査を省略する理由にはなりません。
- 除去方法：公式スクリプトを実行し、2.1.314以降にアップグレードします。必要に応じてホストを再構築してください。
- 認証情報の後処理：Git、CI、クラウド、SSHの認証情報とAPIYIのAPIキーをローテーションします。
参考資料
- Cursorセキュリティ公告：影響を受けるバージョン、IOC、除去スクリプト
- リンク：
cursor.com/blog/claude-code-extension-security-notice - Phorion技術分析：悪意あるコードとバグの分析
- リンク：
phorion.io/blog/offical-claude-code-vsx-compromise - StepSecurity分析：レジストリとバージョンの照合
- リンク：
stepsecurity.io/blog/claude-code-extension-trojanized - Claude Code GitHub Releases：公式バージョンの記録
- リンク：
github.com/anthropics/claude-code/releases
まとめ
今回の事件の特徴は、悪意のあるバージョンが公式パッケージ名を使っていたことです。そのため、「公式の発行元かどうか」だけでは判断できません。推奨される対応順序は、まず拡張機能のバージョンと配布元を確認し、次に公開鍵と永続化の痕跡を調べ、該当する場合は公式スクリプトを実行することです。最後に、信頼できるマシンですべての認証情報をローテーションしてください。APIYI ユーザーは、この機会に「1台につき1つのAPIキー」を基本として、キーのグループ分け、利用上限、有効期限を見直すとよいでしょう。設定方法は、APIYI apiyi.com のトークン管理ドキュメントを参照してください。
著者：APIYI 技術チーム
技術交流：APIYI 公式サイトのトップページからお気軽にお問い合わせください。Claude Code の接続設定については、docs.apiyi.com のドキュメントセンターをご覧ください。
今回はバージョンを変えるだけでは終わりません。最後まで対応すべきなのは、キー、永続化の痕跡、そして認証情報です。
