5000人の開発者は本当にハッキングされたのか？Cursorプラグインへの不正コード混入事件は現在どのような影響を及ぼしているのか？

著者注：この記事では、Cursorの拡張機能に不正なコードが混入した事件について、「影響を受けた可能性があるユーザーは最大5,000人」という数字の本当の意味を解説します。攻撃の流れ、確認済みの事例、APIキーが危険にさらされる範囲、セルフチェックの手順を整理し、根拠のある情報と誇張された主張を見分けます。

2026年10月29日、Cursorの拡張機能マーケットプレイスに、改ざんされたClaude Code拡張機能が登場しました。その後数日のうちに、「5,000人の開発者がハッキングされた」「ClaudeのAPIキーが大量に流出した」といった見出しが広まりました。実際には、5,000人はCursorの公式発表による影響を受けた可能性のあるユーザー数の上限であり、侵入が成功したと確認された件数ではありません。

これはリスクを過小評価するための説明ではありません。Cursorの公式発表に加え、Microsoftのセキュリティ研究チーム、Phorion、Expelなど複数の組織が事件の発生を確認しており、顧客のデバイス上でも悪意のある活動が観測されています。この記事では、「配布、実行、書き込み、悪用可能な状態、実際の侵入、データ損失」の6段階に分けて、どの事実が確認され、どの数字がまだ公開されていないのかを説明します。

この記事でわかること：Cursorの拡張機能に不正なコードが混入した事件が、自分やチームにどのような影響を及ぼす可能性があるかを判断し、公式の推奨手順に沿ってセルフチェックと認証情報のローテーションを行えます。

Cursor拡張機能への不正コード混入事件：概要

まず、確認されている基本情報を整理します。この事件を理解するうえで重要なのは、影響範囲の区別です。これは開発ツールを狙ったソフトウェアサプライチェーン攻撃であり、Claudeモデルが侵害されたわけでも、Anthropicの内部システムが侵害されたわけでもありません。

Anthropicは、これらの悪意のあるビルドを自社が開発・公開したものではなく、事件は同社の内部システムや従業員のコンピューターにも関係していないと説明しています。攻撃者がCursorのマーケットプレイスにビルドを公開する権限をどのように取得したかについては、11月2日時点で調査結果は公表されていません。

Cursor拡張機能への不正コード混入事件：主な時系列

この事件では、混同しやすい2つの時間があります。1つはマーケットプレイスから悪意のあるパッケージをダウンロードできた期間、もう1つはインストール済みの端末で悪意のあるコードが実際に実行された時刻です。後者は前者より大幅に遅くなることもあり、拡張機能の公開が停止されても、ローカル環境が安全になったとは限りません。

当初はOpen VSXが攻撃されたという報道もありました。しかし、OpenSourceMalwareは後にこの見解を訂正しています。また、SocketがOpen VSXのレジストリ記録を調べたところ、該当する悪意のあるバージョンは見つかりませんでした。現時点で攻撃を受けたと確認できる配布経路は、Cursor Marketplaceのみです。

Cursor拡張機能への不正コード混入はどう動くのか：66行のローダーからリバースSSHトンネルまで

PhorionとOpenSourceMalwareの分析によると、攻撃者は正常な拡張機能の extension.js 冒頭に、約66行の悪意あるJavaScriptローダーを挿入しました。通常の処理コードより前に置かれているため、拡張機能のモジュールが読み込まれるだけで実行されます。ユーザーがClaudeにメッセージを送ったり、プログラミング作業を許可したりする必要はありません。Claude Codeの画面や機能は通常どおり使え、一部のエラーも表示されないため、ユーザーは異変に気づきにくい状態でした。

攻撃の流れは、次の6ステップにまとめられます。

1. ホスト情報の収集：ホスト名、ユーザー名、OSとCPUアーキテクチャ、ホームディレクトリ、作業ディレクトリ、Gitのグローバルメールアドレス、グローバルIPアドレスなどを収集します。
2. SSH認証用公開鍵の植え付け：攻撃者が管理する公開鍵をユーザーの authorized_keys に書き込み、svc-telemetry というマーカーを付けます。
3. SSHサービスの有効化を試行：デバイスでSSHログインが可能になれば、攻撃者は植え付けた鍵を使ってログインできる可能性があります。
4. リバースSSHトンネルの確立：被害デバイスから攻撃者のサーバー（TCP 22）へ接続し、その接続をデバイス自身のSSHサービスへ転送することで、一部の受信制限を回避します。
5. 永続化の設定：macOSとWindowsではログイン後に自動再接続するよう設定し、Linuxでは crontab @reboot を使います。これにより、拡張機能がなくてもバックドアが動作します。接続に失敗した場合は、およそ60秒ごとに再試行します。
6. 実行状況の報告：TCP 8099ポートを使うHTTP Beaconで、ホスト情報と各ステップの実行結果をサーバーに送信します。

なぜCursor拡張機能への不正コード混入はプロンプトインジェクションではないのか

「Claude Codeで問題が発生」と聞いて、モデルが悪意あるプロンプトに操られたと思った人も多いかもしれません。今回はそうではありません。これは典型的な拡張機能のコード実行攻撃です。悪意ある処理はモデルの出力とはまったく関係がなく、改ざんされたIDE拡張機能であれば、ほかのものでも同じ原理が成り立ちます。そのため、この事件についてClaudeモデル自体の安全性を論じることに意味はありません。問題として浮き彫りになったのは、開発ツールの拡張機能の配布経路が悪用されると、信頼の連鎖が断ち切られてしまうことです。

悪意あるコードにあった2つの実装上の欠陥

今回の攻撃は、コードの実装ミスによって危険性が一部抑えられていました。macOSでは、悪意あるコードがRemote Loginの状態を確認する際に管理者権限を使わなかったため、システムは「オフ」ではなく権限エラーを返しました。プログラムは「オフ」と明確に認識した場合にしかSSHを有効化しないため、もともとSSHが無効だった多くのMacでは、このステップが失敗します。Windowsでは、OpenSSH Serverのインストール時にUnix形式の /bin/sh を誤って呼び出していました。標準的なWindows環境には、このパスは存在しません。

ただし、欠陥があるからといって無害なわけではありません。悪意あるコードは引き続き、公開鍵の書き込み、永続化スクリプトの生成、ネットワーク接続の開始、ホスト情報の送信を行えます。もともとSSHが有効になっていたデバイスでは、リスクが大幅に高くなります。Phorionの共同創業者Calum Hall氏もWIREDの取材に対し、正しく実装されていれば、非常に危険な攻撃の入口になり得たと語っています。

5000人の開発者がハッキングされたのか：Cursorプラグインへの不正コード混入、その影響を6段階で見る

「5000」という数字は、Cursorが10月29日に公開した初版の告知にある「At most 5,000 users were affected」、つまり影響を受けたユーザーは最大で5000人という記述に由来します。これは公式発表による上限であり、セキュリティ機関が独立して確認した侵害件数ではありません。初版の告知では 2.1.313 のみが挙げられていましたが、更新後に 2.1.312 が追加されました。ただし、各バージョンに該当するユーザー数や、修正後の人数の内訳は公開されていません。

影響を6段階に分けて見ると、何が確認され、何が推測にとどまっているかがわかりやすくなります。

図の左右の差は、ニュースの見出しと証拠の間にある差を示しています。ファネルの下に行くほど、公開されている証拠は少なくなります。「5000台のコンピューターが完全に制御された」「5000人のAPIキーが盗まれた」といういずれの主張も、現時点では裏付ける証拠が見つかっていません。

Expelが確認した4件の実際の事例から何がわかるか

Expelは10月29日から30日にかけて、関連する4件の顧客インシデントに対応しました。対象は4社で、それぞれ1台のMacが関係していました。うち3台はCrowdStrike Falcon、1台はMicrosoft Defender for Endpointを使用していました。4件すべてで攻撃者のサーバーIPへのネットワーク接続が確認されています。このことは、インシデントがすでに実験室でのコード分析にとどまらない段階に達していることを示しています。

特に注目したいのは、実行までに時間差があった事例です。ユーザーが北京時間の10月30日12時44分にMacにログインしてCursorを起動すると、1分後に悪意ある活動が現れました。その後も22時29分まで攻撃者のIPへの接続が続き、最初の検知から約10時間に及びました。この時点で悪意あるパッケージはすでにマーケットプレイスから削除されていたため、公開中にダウンロードされたパッケージが、ユーザーによるCursorの再起動をきっかけに実行されたと考えるのが妥当です。

ただし、これらのデータからわかることには明確な限界があります。4件という数字は世界で被害を受けたデバイスが4台だけだったことを意味せず、4を5,000で割って感染率を算出することもできません。また、SSHトンネルが検出されたからといって、攻撃者がログインに成功したとは限りません。Phorionも顧客のMac上でサンプルを発見していますが、Expelの事例と重複しているかは不明なため、単純に件数を足すことはできません。Expelはまた、悪意あるトンネルプロセスが動作していたものの、svc-telemetryという公開鍵のマーカーが見つからなかったマシンも確認しています。つまり、1つのマーカーだけを検索すると、見逃しが生じやすいということです。

Cursorプラグイン汚染におけるAPIキーのリスク範囲

悪意あるコードは、名前に KEY、TOKEN、SECRET、PASS、AWS、GCP を含む環境変数を最大40件まで抽出します。たとえば、端末に OPENAI_API_KEY が設定されていれば、攻撃者はその端末で対応するサービスが使われていると把握できます。ただし、研究者によると、最初に送信されるのは変数名だけで、変数の値ではありません。

そのため、正確には「攻撃コードは機密設定の種類を識別できる」となります。バックドアが実際に悪用された場合、攻撃者がさらにローカルの認証情報やソースコードを読み取る可能性もあります。一方、実際に何件のAPIキーが盗まれたかについては、現在のところ公開データがありません。「すべてのユーザーのAPIキーが盗まれた」というのは、できることと実際に起きたことを混同した表現です。ただし、リスクの範囲が明確でないからこそ、予防措置として認証情報をローテーションする必要があります。

Cursorプラグイン汚染の影響分析

開発者への影響

• プラグインのアンインストールだけでは不十分：公式は、アンインストールや 2.1.314 へのアップグレードだけでは、すでに書き込まれたSSH公開鍵、スタートアップ項目、バックグラウンドスクリプトを削除できるとは限らないと明確に警告しています。
• 配布停止後も実行される可能性：Expelが報告した遅延実行の事例は、「配布停止後に初めてCursorを開いた」ユーザーも自分の環境を確認する必要があることを示しています。
• SSHを常時有効にしている端末はリスクが高い：開発端末では、リモートデバッグのためにリモートログインを常時有効にしていることがあります。この場合、悪意あるコードの実装上の不具合を回避してしまいます。
• 認証情報の利用状況を把握された可能性：バックドアの悪用に至らなかった場合でも、攻撃者はどのクラウドサービスやAPIを利用しているかを把握している可能性があります。

チームと業界への影響

• プラグインの配布が新たな攻撃対象に：同じ拡張機能でも、マーケットプレイスによってバージョンの提供元が異なる場合があります。判断する際は、バージョン番号だけでなく、インストール元とファイルのハッシュも確認する必要があります。
• AIコーディングツールに与える端末権限の再評価が必要：IDEプラグインは通常、ユーザー権限で動作し、ホームディレクトリの読み書きやネットワーク接続ができます。企業はこれらも端末管理の対象に含めるべきです。
• インシデント対応には認証情報のライフサイクル全体を含める必要がある：影響を受けた端末からアクセスできるリポジトリ、APIキー、クラウドの認証情報、セッショントークンはすべて評価対象にすべきです。プロジェクトで使うキーが分散しているほど、ローテーションの負担も大きくなります。

Cursorプラグインの汚染を自己点検し、認証情報をローテーションする手順

まず、Cursorの公式発表で提供されているmacOS・Windows向けのチェック・修復スクリプトを使うことをおすすめします。以下の指標とコマンドは、状況の理解と調査を補助するためのものです。公式スクリプトの実行やログ調査の代わりにはなりません。

ステップ1：ローカル環境を簡易チェックする（macOSの例）

# 1. 認証済み公開鍵に攻撃者のマーカーがあるか確認（注意：見つからなくても安全とは限らず、見逃しの可能性があります）
grep -n "svc-telemetry" ~/.ssh/authorized_keys

# 2. 永続化用ファイルと起動項目を確認
ls -la ~/.config/.smt ~/.config/.smtk ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# 3. 悪意のあるサーバーへの接続があるか確認
lsof -nP -i | grep "134.209.82.225"

# 4. Remote Loginの状態を確認（管理者権限が必要）
sudo systemsetup -getremotelogin

Windowsでは、schtasks /query /tn SysMon でスケジュール済みタスクを確認し、スタートアップフォルダー内に sysmon.cmd がないか調べます。いずれかに該当した場合は、証拠を保全してデバイスを隔離し、公式スクリプトに従って駆除してください。デバイスを信頼できる状態に戻せない場合は、OSの再インストールを検討し、別の信頼できるデバイス上で認証情報をローテーションしてください。

ステップ2：漏洩した可能性のある認証情報の変数名を洗い出す

以下のスクリプトは、悪意のあるコードと同じキーワードで環境変数を絞り込み、値は表示せず、名前だけを表示します。ローテーションが必要な認証情報のリストアップに役立ちます。ローテーション後は、シンプルなAPI呼び出しで新しいAPIキーが使えることを確認しましょう。

import os, re, openai

# 与恶意代码相同的关键词，列出可能被“摸底”的变量名
pattern = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")
print([k for k in os.environ if pattern.search(k.upper())])

# 在可信设备上轮换后，用新 Key 验证调用
client = openai.OpenAI(
    api_key=os.environ["NEW_API_KEY"],
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 兼容接口
)
r = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "ping"}]
)
print(r.choices[0].message.content)

import os
import re
import openai
from typing import List

KEYWORDS = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")

def list_sensitive_env_names(limit: int = 40) -> List[str]:
    """只返回疑似凭证的环境变量名称，绝不输出值。
    limit 与恶意代码的筛选上限保持一致，用于还原攻击者可能看到的视图。"""
    names = [k for k in os.environ if KEYWORDS.search(k.upper())]
    return sorted(names)[:limit]

def verify_new_key(model: str = "gpt-4o-mini") -> bool:
    """轮换后验证新 Key 是否可正常调用"""
    client = openai.OpenAI(
        api_key=os.environ.get("NEW_API_KEY", ""),
        base_url="https://api.apiyi.com/v1"
    )
    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": "ping"}],
            max_tokens=10
        )
        return bool(resp.choices[0].message.content)
    except Exception as e:
        print(f"验证失败: {e}")
        return False

if __name__ == "__main__":
    print("可能暴露给攻击者的变量名：")
    for name in list_sensitive_env_names():
        print("  -", name)
    print("新 Key 验证结果：", verify_new_key())

ステップ3：優先順位に従って認証情報をローテーションする

🎯 技術的なアドバイス：プロジェクトがOpenAI、Claude、Geminiなど複数のプラットフォームに直接接続している場合、問題発生後はそれぞれの管理画面にログインしてAPIキーを失効・再発行する必要があります。公式では、モデル呼び出しを APIYI apiyi.com に集約することを推奨しています。1つのAPIキーで複数の主要モデルを利用でき、インターフェースはOpenAIと互換性があるため、ローテーション時は設定を1か所変更するだけで済みます。利用量を一元的に確認し、異常な消費を発見しやすくなる点もメリットです。

よくある質問 FAQ

Cursorプラグイン汚染事件の要点 Key Takeaways

• 事件の性質：Cursorのマーケットプレイスで改ざんされた拡張機能が配布されたサプライチェーン攻撃であり、Claudeモデルの脆弱性ではありません
• 5000人の意味：公式が示した影響を受けた可能性のある人数の上限であり、侵入が確認された人数ではありません
• 確認されていること：独立機関が実際のMac上で悪意ある動作と外部通信を観測しています
• 公表されていないこと：リモートログインに成功された人数、盗まれたキーの数、経済的損失
• 主なリスク：公開停止後も悪意あるコードが実行される可能性があり、プラグインのアンインストールだけではバックドアを完全に除去できるとは限りません
• 対処方法：公式スクリプトを実行し、信頼できるデバイスで認証情報をローテーション。APIYI apiyi.com を活用してキーの数を集約します

まとめ

Cursorプラグイン汚染事件の要点は次のとおりです。

1. 見出しと証拠を区別する：「最大5000人が影響を受けた可能性がある」ことと「5000人がハッキングされた」ことの間には大きな隔たりがあります。現在公開されている証拠で確認できるのは、「実際に悪意あるコードが実行された事例がある」という段階までです。
2. 攻撃は実在するが、成功率には制約があった：悪意あるコードにはバックドアと永続化の機能がありましたが、macOSとWindowsでの実装上の欠陥により、リモートログインの成功率は低下していました。
3. 自己確認は一項目だけでは不十分：インストール元、ファイルのハッシュ、プロセス、ネットワーク接続、スタートアップ項目を組み合わせて確認しましょう。svc-telemetry だけを検索すると見逃す可能性があります。

10月29日から30日にかけてCursorのマーケットプレイス経由でClaude Code拡張機能を使用した方は、まず公式ガイダンスに従って自己確認を行い、優先度に応じて認証情報をローテーションしてください。モデルのAPIについては、この機会に分散したキーをAPIYI apiyi.com に集約しておくと、次に緊急ローテーションが必要になった際の手間を減らせます。

📚 参考資料

1. Cursor 公式セキュリティアナウンス：事件の発生時期、バージョン、悪意あるファイルのハッシュ、クリーンアップスクリプト
2. リンク：cursor.com/blog/claude-code-extension-security-notice

3. 説明：セルフチェックの際にまず参照したい公式発表です。macOS と Windows の修復スクリプトが含まれています

4. Microsoft Security Research：悪意ある Claude Code 拡張機能の攻撃チェーン分析

5. リンク：microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/

6. 説明：サプライチェーンの境界、SSH の仕組み、永続化の詳細を確認できます

7. Phorion：Official Claude Code Extension Compromise

8. リンク：phorion.io/blog/offical-claude-code-vsx-compromise/

9. 説明：66 行のローダー、プラットフォーム間の違い、コードの欠陥に関する技術的な詳細を確認できます

10. Expel：Fake Claude Code extensions in Cursor

11. リンク：expel.com/blog/blog-fake-claude-code-extension-cursor-ssh-backdoor/

12. 説明：実際に顧客環境で発生した 4 件のインシデントと、遅延実行の事例を紹介しています

13. Socket：Cursor Removes Malicious Claude Code Extension

14. リンク：socket.dev/blog/claude-code-extension-compromise
15. 説明：Open VSX と npm の記録を検証し、初期の誤報を訂正しています

著者：APIYI 技術チーム
技術に関するお問い合わせ：APIYI の apiyi.com トップページからお気軽にお問い合わせください。その他の導入資料は docs.apiyi.com のドキュメントセンターをご覧ください

関連記事

• Claude Code拡張機能に不正コード混入：2.1.313のバックドアを5ステップで点検・除去:10月29日、Cursor Marketplaceの公式Claude Code拡張機能のバージョン2.1.312と2.1.313がSSHバックドアを含むビルドに差し替えられ、最大5,000人のユーザーが危険にさらされた事案について、この記事ではsvc-telemetry公開鍵の確認、LaunchAgentやスケジュールタスクなどによる永続化の排除、バージョン2.1.314以降への更新、GitHub・クラウド認証情報・APIYIキーのローテーションを5ステップで解説し、事案の確実な収束を支援します。
• Claude MaxがUltraに改名、5時間の制限は撤廃された？まず押さえたい3つの変更点:Claude Max 20xはUltra、Max 5xはMaxに名称変更され、料金は据え置き、認証済みUltraアカウントの5時間制限は撤廃されますが週間上限は変わらず、この記事では比較表、3ステップのセルフチェック、料金計算を通じてプランを変更すべきか判断できます。