Cursorマーケットでトロイ化されたClaude Code拡張が流通——開発端末に永続SSHバックドア、AIコーディング時代の新たな供給網リスクです

今日の深掘りポイント

• AIコーディング拡張は「高権限・広権限・即時実行」の三拍子がそろう新たな攻撃面です。正規機能の陰に仕込む“静かな永続化”は検出が難しいです。
• 本件はサプライチェーン型の初期侵入であり、拡張の削除だけでは足りず、SSH鍵や開発者トークン、CI/CDシークレットを含む広範なローテーションが必須です。
• authorized_keysの改変はEDRが見落としやすい持続化手口です。端末隔離と「authorized_keys差分」「外向きSSH通信の監査」「マーケットプレイス由来のインストールイベント可視化」の三点が肝です。
• 公式のVisual Studio Marketplaceやnpm配布が無関係という点は、同名・類似エコシステム間での“偽の安心感”を誘う落とし穴を示します。ツールチェーンごとに信頼連鎖を検証する体制が要ります。
• 緊急性と実務的な可搬性が高い事案です。すぐ動ける組織ほど被害半径を小さくできます。

はじめに

開発者が日常的に使う拡張機能は、もはやIDEの便利機能にとどまらず、OSファイルシステムやネットワーク、認証情報に接触しうる“準特権プロセス”になりつつあります。そこに「AIコーディング支援」という新しいユースケースが重なると、より深いOS APIやプロジェクト資産へのアクセスが許容されがちです。今回のCursorマーケットプレイスでのトロイ化拡張配布は、この構造的な盲点を突いた典型例と言えます。開発端末の侵害は単一端末の問題ではなく、リポジトリ、CI/CD、署名鍵、顧客へのソフトウェア出荷——と、被害はサプライチェーン全体へと波及します。熱量のあるプロダクティビティの裏側で、攻撃者もまた速度を上げていることを、私たちは直視すべきです。

深掘り詳細

事実関係（確認済み）

• 悪意のあるClaude Code拡張がCursorマーケットプレイス経由で配布され、開発者端末に持続的なSSHバックドアを仕込む挙動があったと報告されています。正規機能に混ぜ込む形でJavaScriptが注入され、無許可のリモートアクセス準備が行われたとされています。
• Microsoftは、これらのトロイ化パッケージがSSHおよびHTTPの宛先として134.209.82[.]225へ接続を試行する点を指摘しています。
• Cursorは2026年10月29日に本件を公表し、影響のあった時間帯を特定したとしています。
• Microsoftは、Visual Studio MarketplaceやClaude Codeのnpm配布には影響がないことを確認しています。
• 一部報道では、問題のバージョンとしてv2.1.312/313が挙げられています（出所は下記参考情報）です。
  出典: GBHackersの報道

注記: 本稿の事実は公開情報に基づき、現時点で確認可能な範囲に限って記載しています。タイムラインやハッシュ、追加のIoCは今後の続報で更新される可能性があります。

インサイト（編集部の視点）

• 供給網の粒度が細分化していることが本件の本質です。従来は「公式ストア＝相対的に安全」という前提が働きましたが、同名・類似名のエコシステムや、ベンダごとに独立した拡張流通経路が増え、信頼連鎖の検証が難しくなっています。「正規パッケージに似たもの」「正規機能＋小さな追加コード」という“グレーの領域”は審査やスキャンの目をすり抜けがちです。
• 永続化にSSH公開鍵を用いるアプローチは、マルウェア亜種やサービス登録のような派手なアーティファクトを残しません。authorized_keysやssh_configの改変は、EDRの標準ルールや脅威ハンティングの目線から外れやすく、加えて開発者自身がキーローテーションの頻度を下げている組織では、長期の潜伏が可能になります。
• AIコーディング拡張は、プロジェクトルート、リポジトリ、ビルドスクリプト、シークレット管理ファイルへのアクセス機会が多く、盗まれたトークン（GitHub/GitLabのPAT、クラウドCLI資格情報、パッケージレジストリのトークン）を足掛かりに、CI/CDやリリース工程への水平展開が現実的です。拡張単体の削除で「元に戻った」と考えるのは危険です。
• 現場への示唆としては、「拡張の入手先の正当性検証」「拡張の許可リスト化」「開発端末の外向きSSH/HTTP通信の制御」「authorized_keysの整合性監査」を、イベントレスポンスと常設対策の両輪で進めるべきです。

脅威シナリオと影響

以下は現時点の公開情報に基づく仮説シナリオであり、MITRE ATT&CKのテクニックに沿って整理します。実環境の分析で裏取りすることを強く推奨します。

• 初期侵入（Initial Access）

  • サプライチェーン妥協（T1195: Supply Chain Compromise）
    • マーケットプレイス経由でのトロイ化拡張の取得。
  • ユーザー実行（T1204: User Execution）
    • 開発者が手動で拡張を導入・更新。

• 実行・準備（Execution/Preparation）

  • スクリプト実行（T1059: Command and Scripting Interpreter）
    • 注入されたJavaScriptが環境情報収集や設定変更を実施。

• 発見（Discovery）

  • システム情報の探索（T1082: System Information Discovery）
  • アカウント情報の探索（T1033: Account Discovery）
    • Node.js API等でホスト名、ユーザー名、OS情報を収集（報道の技術説明に基づく）。

• 永続化（Persistence）

  • アカウント操作: SSH Authorized Keys（T1098.004）
    • ~/.ssh/authorized_keysへの公開鍵追加による静的な持続化。

• 防御回避（Defense Evasion）

  • 偽装（T1036: Masquerading）
    • 正規拡張に見せかけた機能提供とコード注入。
  • 難読化/圧縮（T1027: Obfuscated/Compressed Files and Information）
    • 具体の実装は要確認ですが、一般に検出回避で併用されがちです（仮説）。

• コマンド&コントロール（Command and Control）

  • リモートサービス: SSH（T1021.004）
    • 134.209.82[.]225 へのSSH/HTTPトラフィック誘導（報道のIoCに基づく）。

• 運用上の影響（仮説）

  • 資格情報アクセス（T1552: Unsecured Credentials）
    • 開発環境に残置されたトークン・鍵の窃取。
  • 水平移動と供給網汚染
    • リポジトリ改ざん、依存パッケージのトロイ化、CI/CDのシークレット窃取から顧客配布物への逆流入。

本シナリオに沿うと、短期は開発者端末の持続的乗っ取り、中期はリポジトリ/CIの汚染、長期は製品や顧客環境への波及という三層のリスクとなります。早期に“端末→リポジトリ→CI/CD→配布物”の鎖を断ち切ることが被害最小化の鍵です。

セキュリティ担当者のアクション

優先度順に、現実装に移しやすい具体策を整理します。

• 直ちにやること（0–24時間）

  • 影響の疑いがある端末を網羅的に特定し、ネットワークから隔離します（EDR/MDMのタグ付けで封じ込めるのが理想です）。
  • 当該拡張が導入・更新された事実を資産管理/ソフトウェアインベントリで突合します（例: 管理対象端末の拡張一覧、開発VDI/クラウドIDEの監査ログ）。
  • ~/.ssh/authorized_keys の新規行・末尾行・不審コメントの差分を確認し、業務用鍵リストと照合します。改変が疑わしければ鍵を撤去のうえ、直ちに鍵ペアをローテーションします。
  • プロキシ/ファイアウォール/DNSログで 134.209.82[.]225 宛てのHTTP/SSH通信の有無を検索し、ヒット端末を高リスク群として優先対応します（ブロックも即時実施します）。

• 資格情報・信頼の再確立（24–72時間）

  • 開発者のSSH鍵、GPG署名鍵、GitHub/GitLabのPAT/トークン、パッケージレジストリ（npm/Container Registry等）のトークン、クラウドCLI（AWS/GCP/Azure）の長期資格情報を全ローテーションします。
  • リポジトリの保護分岐（default branch）への強制署名、保護ルール、ブランチ保護の再適用・強化を行います。
  • CI/CDのリポジトリ・環境・組織シークレットを点検し、不要なスコープを削減のうえで再発行します。直近の実行履歴で不審なジョブ実行がないかを確認します。

• 根絶・ハンティング

  • macOS/Linuxの開発端末で、ssh_config、known_hosts、LaunchAgents/cron、シェル初期化ファイル（.bashrc/.zshrc）に不審な追記がないかパス単位で棚卸します。
  • EDR/HIDSに「authorized_keysの変更」「外向き22/tcpの新規フロー」「IDE拡張ディレクトリへの異常な書き込み」を検知条件として追加します。
  • 端末ローカルのnpmキャッシュや拡張キャッシュからの再感染を防ぐため、キャッシュと一時フォルダをクリーンアップし、信頼済み配布元からのみ再展開します。

• ガバナンスと恒久対策

  • 拡張機能の導入を「許可リスト型」に転換します。検証済みベンダ署名、ハッシュピン留め、配布源URLピン留めを条件化します。
  • 開発端末の外向きSSHを原則遮断し、踏み台（bastion）経由に限定します。HTTP/HTTPSもSNI/ドメインベースで許可制を強化します。
  • Dev環境の機密境界を再設計します。個人端末ではなくVDI/クラウドIDE（短命・再作成前提の環境）を活用し、資格情報は短寿命化・スコープ極小化します。
  • 「マーケットプレイス由来の更新」を含むサプライチェーン型インシデントの机上演習を、開発・SRE・セキュリティ合同で実施します。復旧手順（鍵・トークン・署名証明書の一斉ローテーション）をプレイブック化します。
  • セキュリティ教育では「便利そうな拡張＝即導入」の心理的ハードルを設けます。導入申請フロー、リスクラベル（要OSSレビュー/要スキャン/要隔離環境）の明示が有効です。

今回の案件は、新規性・即応性・実務的アクションの三点で優先度が高いと総合評価できます。拡張の削除で終わらせず、「信頼の再構築」と「開発環境の最小権限・短寿命化」を軸に、供給網の鎖を一つずつ堅牢にしていくことが、長い目で見て最も費用対効果の高い投資になります。

参考情報

• Hackers Distribute Malicious ‘Claude Code’ Extension via Cursor Marketplace (GBHackers)